Transaction deadlocks

["McCarrier, Alex" <am...@pointserve.com>]

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.

Re: Transaction deadlocks

[Brandon Goodin <br...@gmail.com>]

When set to External it is your responsibility to manage the
transactions. IBatis will not handle them automatically.

Brandon


On Tue, 7 Dec 2004 11:02:08 -0600, McCarrier, Alex
<am...@pointserve.com> wrote:
> 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.
>