This might be a good thing to note for others who are going through the pain of upgrading from iBatis 1 to iBatis 2. In iBatis 1 there was no endTransaction() call. You called startTransaction, then either commitTransaction or rollbackTransaction. After upgrading to iBatis 2, the code still runs, but since the old code didn't have a call to endTransaction (it didn't exist), you will now risk hanging your JVM.
If you are using these methods, make sure you add an endTransaction() call every where you have a commitTransaction(). -----Original Message----- From: McCarrier, Alex [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 07, 2004 2:44 PM To: [EMAIL PROTECTED] Subject: RE: Transaction deadlocks -- SOLVED In iBatis 1.2.x one of our developers had put start/commit transactions around start/end batch updates to work around a bug in iBatis. There was no endTransaction call. Shortly after this, the next few statements would eventually deadlock. The fix was to either add the endTransaction call, or to remove the start/commit transaction calls altogether since they aren't really needed (transactions provided by EJB), and the bug that we were originally working around no longer exists in iBatis 2. -----Original Message----- From: McCarrier, Alex [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 07, 2004 1:28 PM To: [EMAIL PROTECTED] Subject: RE: Transaction deadlocks -- update So what I thought was transaction related seems to be related to something else... I'm still getting these deadlocks even when I manually control the transactions. It's just that by manually controlling the transaction, I stopped getting the deadlock on one particular test, but now other tests are deadlocking when they are inside a transaction. -----Original Message----- From: McCarrier, Alex [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 07, 2004 11:02 AM To: [EMAIL PROTECTED] Subject: Transaction deadlocks I'm running into the following scenario: In my unit tests, when I'm testing basic CRUD functionality, on the removal of an object that has an aggregate relationship with other objects, I the JVM hangs indefinitely. This happens consistently when I have one object that contains a list of other persistent objects. When we remove the parent object, this triggers a cascade delete on the contained objects. After the final removal of the parent objects, when the ibatis code calls the JDBC PreparedStatement.execute method, the JVM never returns from that method. This seems to be somehow related to transactions. If I specifically demarcate the transaction using start/commit/end transaction whenever I'm doing one of these cascade delete operations, it works fine. If I rely on the ibatis framework for doing automatic transactions, then I get these deadlocks, but they only seem to show up in these cascade delete scenarios. One thing to note, is that my transaction manager is set to external, however in these particular unit tests, there is nothing that sets the transaction since these tests are not calling through an EJB (where we normally have our transaction boundaries declared). So this begs the question, do automatic transactions only work when the TransactionManager type is JDBC? This is on iBatis 2.0.8, Oracle 9, and Jboss 3.2.1.
