Ah, yes. If you're using the wrappers for JDBC 1/2 drivers (that
is, your vendor doesn't provide a native XADataSource), then there's not
much you can do to work around this. There is no way you can tell a
Connection which Xid or Transaction it should be associated with - there's
a one-to-one mapping. We planned to set it up so that if you're using the
wrapper, you can only get one connection for any particular Xid.
The problem with this is that the desired result isn't clear: you
can either return the same connection object for every request, or throw
an exception for all requests after the first. In the first case, it's
not clear how to handle closing (does the connection close after the first
or last close call?). In the second case, you may be prevented from doing
some legitimate things (using one table in two beans, and you can't really
pass the connection from one to the other).
I'm open to suggestions for the best way to handle this. I would
lean towards return the same connection for all calls, but we would
definitely need this to be clearly documented.
Aaron
On Sun, 30 Jul 2000, Jason Sando wrote:
> Good luck with Tyrex, it won't compile from CVS and hasn't been updated in
> months.
>
> As for the "problem" with Minerva/IDB/JTA, here's the dope:
>
> 1. Start a new transaction via JTA
> 2. Allocate connection C1
> example: Connection c1 = ((DataSource) ctx.lookup
> (JNDI_NAME_DS)).getConnection ()
> 3. Do an update against Table T1 using C1
> 4. Allocate a second connection C2
> 5. Do a select from Table T1 using C2
> 6. System is now deadlocked!
>
> I think the problem is that IDB does table-level locking and tracks the lock
> owner using the java.sql.Connection object. But with XA, the Xid is the
> owner of the lock. In the example above, although there's only one Xid,
> there's two separate Connection objects returned by Minerva. C1 holds the
> lock on T1 until the commit, but C2 is trying to read it before then.
>
> Sound reasonable? Or is it my half-baked JTA?
>
> ;-J
