Thanks all for providing some valuable ideas on this issue. Here is an answer to some of the questions :
- The locking policy is 'committed read' for all the database accesses. Which means that the process/transaction/thread (B) should not have a problem reading the row from table A, when process (A) rolls back and has already completed.
- Transaction scope has been set properly
- We are using Websphere's connection pooling, and I have not in my experience seen any problem with the pooling. Since, we are using EJB transactionality, the container should take care of the overall commit or overall rollback
- We are in the process of doing database monitoring to see if we can find any more clues.
- The process X and Y are the consecutive threads from a Websphere's MDB listener and we have set the Session = 1, so that threads are executed serially. We see the problem when the subsequent threads are executed in a window of 500 ms. We don't see any issues beyond that window.
- Tables A and B are in the same database, so we are not using database links. The other things happening in the processes is irrelevant to the issue. Trust me when I say that.
- And we are very new to Oracle, Java, DB2, Mainframe etc. That is not true, but if hat makes you happy.
Thanks!
--
Message posted via http://www.oraclemonster.com
Received on Fri Jan 07 2005 - 10:54:26 CST
