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
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Mulder
> Sent: Saturday, July 29, 2000 5:42 AM
> To: jBoss Developer
> Subject: RE: [jBoss-Dev] TransactionImpl
>
>
> There are definite deficiencies in the current implementation.
> We're planning to integrate a 3rd party JTA implementation. Judging my
> Marc's last e-mail, it looks like Tyrex is the target of choice! :)
> Can you be more specific about any problems with Minerva? That we
> would like to correct, not replace, though I'm not clear from your message
> whether the problem lies with Minerva, InstantDB, Informix, or the JTA
> implementation.
>
> Thanks,
> Aaron
>
> On Fri, 28 Jul 2000, Jason Sando wrote:
> > In the code below from jBoss, in delistResource its calling
> XAResource.end
> > (xid, Status.STATUS_ACTIVE), which is not even a valid parameter, except
> > possibly by coincidence. Is it supposed to be
> XAResource.TMSUCCESS? Are
> > resources not allowed to fail?
> >
> > I have a non-distributed implementation of JTA that is further
> along than
> > jBoss but nowhere near Tyrex. I built it with Tyrex, jBoss,
> Jonas, and the
> > JTA spec in hand. I did NOT have the XA Spec, although I've
> just ordered
> > it.
> >
> > When I started testing I entered a world of pain. First, using
> Minerva XA
> > wrappers with InstantDB I hit deadlock problems. Then with
> Informix JDBC
> > 2.11 the second XAResource hangs on a socket read and the server never
> > responds. So I gave up, made a "fake" JTA for my immediate needs, and
> > ordered the XA spec.
> >
> > Has anybody had success with JDBC/XA (with more than one XAResource
> > involved)?
> >
> > If you're interested in more detail/code let me know.
> >
> > ;-J
> >
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury
> > > Sent: Thursday, July 27, 2000 5:56 PM
> > > To: jBoss Developer
> > > Subject: RE: [jBoss-Dev] TransactionImpl
> > >
> > >
> > > Carlos,
> > >
> > > 1- Please restrain from sending formated text, send plain text
> > > when you can
> > >
> > > 2- I just came back from a deep dive in the current TM package. To be
> > > honest it is not really up to snuff and I am considering nipping it
> > > altogether. I have put stop gap fixes in there just to get the
> > > TxInterceptor and the container behaving properly.
> > >
> > > You seem a fellow keen on JTS/JTA do you have spare cycles for the
> > > integration of a TM?
> > > When I integrated Jonas' TM it took me a day (most the code is
> > > simple) heck
> > > I'll do it.
> > >
> > > marc
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Carlos Pita
> > > Sent: Thursday, July 27, 2000 5:44 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: [jBoss-Dev] TransactionImpl
> > >
> > >
> > > Hi!
> > >
> > > I have a question (it could be an observation if already had more
> > > self-confidence) about enlisting/delisting xa resources in
> the Transaction
> > > implementation. Here are the sources of both methods as they
> were in last
> > > week CVS repository (remember that resources is a Vector):
> > >
> > > public boolean delistResource(XAResource xaRes, int flag)
> > > {
> > > try {
> > > xaRes.end(xid, Status.STATUS_ACTIVE);
> > > // resources.removeElement(xaRes);
> > > return true;
> > > } catch(XAException e) {
> > > e.printStackTrace();
> > > return false;
> > > }
> > > }
> > >
> > > public boolean enlistResource(XAResource xaRes)
> > > throws RollbackException
> > > {
> > > // Check rollback only
> > > if (status == Status.STATUS_MARKED_ROLLBACK)
> > > {
> > > throw new RollbackException();
> > > }
> > >
> > > // Add resource
> > > try {
> > > xaRes.start(xid, Status.STATUS_ACTIVE);
> > > resources.addElement(xaRes);
> > > return true;
> > > } catch(XAException e) {
> > > e.printStackTrace();
> > > return false;
> > > }
> > > }
> > >
> > > When the transaction commits (or rollback) the algorithm is:
> > > [...]
> > > for (int i = 0; i < resources.size(); i++)
> > > {
> > > try
> > > {
> > >
> ((XAResource)resources.elementAt(i)).commit(xid, false);
> > > } catch (XAException e)
> > > {
> > > try {
> > > ((XAResource)resources.elementAt(i)).forget(xid);
> > > } catch(XAException another) {}
> > > e.printStackTrace();
> > > // TODO: what to do here?
> > > }
> > > }
> > >
> > > So the question is:
> > >
> > > What if we have more than one xa resource enlisted in the transaction
> > > corresponding to the same resource manager? I think that in
> this scenario
> > > the algorithm will run the 2 phase protocol against the same resource
> > > manager and for the same transaction more than once.
> > >
> > > Regard this, the JTA spec says:
> > >
> > > "
> > > The enlistResource request results in the Transaction Manager
> > > informing the
> > > resource manager to start associating the transaction with the work
> > > performed through
> > > the corresponding resource�by invoking the XAResource.start
> method. The
> > > Transaction Manager is responsible for passing the
> appropriate flag in its
> > > XAResource.start method call to the resource manager. The XAResource
> > > interface
> > > is described in section 3.4.
> > > If the target transaction already has another XAResource object
> > > participating in the
> > > transaction, the Transaction Manager invokes the
> > > XAResource.isSameRM method
> > > to
> > > determine if the specified XAResource represents the same
> resource manager
> > > instance.
> > > This information allows the TM to group the resource managers who are
> > > performing
> > > work on behalf of the transaction.
> > >
> > > 1.Transaction Branch is defined in the X/Open XA spec [1] as
> follows: 'A
> > > global transaction has one or
> > > more transaction branches. A branch is a part of the work in
> support of a
> > > global transaction for which the
> > > TM and the RM engage in a separate but coordinated
> transaction commitment
> > > protocol. Each of the RM�s
> > > internal units of work in support of a global transaction is part
> > > of exactly
> > > one branch. .. After the TM begins
> > > the transaction commitment protocol, the RM receives no
> additional work to
> > > do on that transaction branch.
> > > The RM may receive additional work on behalf of the same
> transaction, from
> > > different branches. The differ-ent
> > > branches are related in that they must be completed atomically. Each
> > > transaction branch identifier (or
> > > XID) that the TM gives the RM identifies both a global
> transaction and a
> > > specific branch. The RM may use
> > > this information to optimise its use of shared resources and locks.'
> > > "
> > >
> > > That's all for now.
> > > Thank you,
> > > Carlos
> > >
> >
> >
>
>
>
