My humble opinion:
Another possibility is to build it on top of a Java orb with a
transaction service implementation (it could be JavaORB, which has a lot of
other services implemented too). Then jBoss could use a POA to export iiop
beans (I think using a servant manager as CCM dictates gives jboss a hook to
use all the jBoss plugin machinery -pools, persistence, etc- ), it could
gradually take adventage of corba security, corba persistence, corba events
and it could gradually align with CCM. This could (and should) be
evolutionary (and I think it fit well with the jboss modular architecture).
(CCM=Corba Component Model)
Carlos.
----- Original Message -----
From: marc fleury <[EMAIL PROTECTED]>
To: jBoss Developer <[EMAIL PROTECTED]>
Sent: Saturday, July 29, 2000 1:35 PM
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! :)
>
> 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
> > > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
