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
> >
>
>
