> 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! :)
Well what else is out there? We have done JOnAS, been there done that,
worked ok in jboss1.0.
We need a change :) and Tyre looks like it is worth a try, we know what
Assaf can do ;-)
marc
> 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
> > >
> >
> >
>
>
>
>
>
