So its in the plans but not there yet, eh?
I think your first pitch is the required one: return the same Connection all
the time for requests against the same Xid (ie, XAResourceImpl.start will
have to allocate the Connection). Then, even though close() is called,
don't dissociate the Connection until XAResource.commit(),
XAResource.rollback(), an XAResource.prepare() that fails, and possibly an
XAResource.forget().
Something like that?
;-J
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Mulder
> Sent: Sunday, July 30, 2000 11:25 AM
> To: jBoss Developer
> Subject: RE: [jBoss-Dev] TransactionImpl
>
>
> 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
>
