I agree too.
----- Original Message -----
From: danch <[EMAIL PROTECTED]>
To: jBoss Developer <[EMAIL PROTECTED]>
Sent: Monday, July 31, 2000 10:49 AM
Subject: Re: [jBoss-Dev] TransactionImpl
> Jason Sando wrote:
> >
> > 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().
> I agree. I think that's the only we to make the wrapper work with
> typical usage and ensure that if two beans are written to the same
> database in the same transaction they can both be rolled back by that
> transaction
>
> danch
>
> >
> > 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
> > >
>
>
