informix jdbc driver problem?

I am getting some intermittent exceptions during the execute() call of a prepared statement. It is a multi-threaded application running on Solaris. Using jdk 1.1.5, native threads, and the weblogic type 4 jdbc driver (3.1). Here are some examples of the seemingly random exceptions being caught: (any help appreciated) Informix error: -239 minor code=[-100] [ at processUpdate <Error> ] See Informix error codes for explanation Informix error: 6 minor code=[203] [ProcessUpdate: Expected packet ID but got: 8 and 00,06,00,CB,00,00,00,00,00,38,00,01,00,05,00,00, // - Ë 8 - - 00,00,00,0C, // -] See Informix error codes for explanation Informix error: 0 minor code=[15] [Expected packet ID but got: 56 and 00,00,00,0F,00,00,00,00,00,00,00,00,00,00,00,00, // - 00,00,00,37,00,00,00,01,00,00,00,01,00,0C, // 7 - - -] See Informix error codes for explanation Informix error: 1 minor code=[41] [Expected packet ID but got: 15 and 00,01,00,29,F5,0A,00,00,00,00,00,37,00,00,04,DB, // - )õ- 7 -Û 00,00,00,A3,00,0C, // £ -] See Informix error codes for explanation Informix error: 0 minor code=[0] [Expected packet ID but got: 12 and 00,0C, // -] See Informix error codes for explanation:

bstaib wrote: > I am getting some intermittent exceptions during the execute() call of a > prepared statement. It is a multi-threaded application running on > Solaris. Using jdk 1.1.5, native threads, and the weblogic type 4 jdbc > driver (3.1). Here are some examples of the seemingly random exceptions > being caught: > (any help appreciated) > > Informix error: -239 minor code=[-100] [ at processUpdate <Error> ] See > Informix error codes for explanation > > Error -239 reports: "Could not insert new row - duplicate value in a UNIQUE INDEX column. The row that is being inserted (or being updated to have a new primary key) contains a duplicate value of some row that already exists, in a column or columns that are constrained to have unique values. The row is not inserted. Roll back the current transaction, and execute it again without any duplicate rows." Have you convinced yourself that this error is being incorrectly reported? In your multi-threading environment is it at all possible that there are unexplored locking issues? Is one thread updating a row that another thread is assuming has not been changed? Cheers-- Charles