Hi All,
here are some comments on support for distrubuted TX in JBoss.
Marc asked for a scenario showing the need for distributed TX so I made one
up:
>From a SessionBean I'd like to update an EntityBean in my JBoss 2.0 Final
release Server X, I'd also like to to update another system Y (running IAS),
the server Y should then write to IBM:s MQSeries (having a XA-interface) and
to EJB Server Z (running iPAS).
If I'd like to have ACID properties for this multi-vendor, multi-host,
multi-system, multi-... update scenario I guess that a proprietory
TX-propagation solution won't do the job... I'd like to have IIOP support.
Though I haven't read the EJB2.0 spec in detail I think that it mandates
IIOP-support. As for propagating TX contexts the CORBA OTS uses a featute
called Service Context Lists (ctx id - bytearray mappnings). I know that
both Inprise Application Server and IONA:s iPortal Application Server uses
the CORBA OTS for distributed TX.
If you add IIOP support you could send TX-context around multiple vendor
EJB-servers, e.g. As for creating TX context:s you could plug in an OTS
implemention and get a TX from its TX-factory (possibly running on another
host and possibly written in another language than Java).
To conclude:
I agree that in-process transactions are much faster than distributed
transactions and that most systems won't need distributed TX. However this
does not rule out the need for distributed TX (as outlined in the scenario
above - and I have stepped across this problem in real life making calls
from an EJB server to a CORBA Server that was updating another database).
I'm also aware of the fact that 2-PC really isn't totally secure (e.g. after
collecting the votes the TX and issuing commit orders the
coordinator/manager would not see if all commits actually succeded or not).
I guess that the bottom line is that I think that IIOP-support is more
important than support for distributed TX and that distributed TX could
(should) be implemented over IIOP/CORBA OTS:-)
Cheers,
Per
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury
> Sent: Friday, September 29, 2000 9:30 PM
> To: jBoss Developer
> Subject: RE: [jBoss-Dev] TODOS for FINAL
>
>
>
> > > To me, distributed transactions goes hand-in-hand with clustering.
> > Clustering is
> > > of quite limited use without it.
> >
> > Disagree. Clustering is still very very useful. Once a remote
> > call reaches a
> > cluster node all interaction will be local, at least in the first
> > version of
> > the clustering, so there is no need for distributed transactions
> > initially.
>
> I had missunderstood the question, yes rickard is right, the
> distributed TM
> buys us nothing in clustering provided we do the right thing.
>
> The right thing is of course to separate the naming space
> that is global and
> the local name space. If we make sure that the local
> namespace is inVM (as
> it is today) then all the beans you will start from the first
> bean WILL run
> in the same VM. BTW I would argue that this is the right way
> to run your
> application *anyway* because of the speed increment that you
> will see. In
> other words, the important part is the clustering of
> applications *as a
> whole* on one stack and replicate the stack in clustering as
> opposed to one
> part of the application in one set of machines and one other
> part on another
> set, due to the RMI overhead. BTW it is the same approach we
> are taking
> with jboss+tomcat, that we will replicate the stack of
> pancakes interceptors
> in many VMs and that is the simplest way to do it and the fastest.
>
> The part is still to be designed (we are designing it *right now* with
> Rickard) is the global namespace and its clustered visibility
> and the kid
> has a few tricks up his sleeves (and as long as I can understand and
> validate them, since well you know ..., it will be in). That
> is what we
> intend to do for the final jboss2.0. That is a change of
> plans btw before
> we were going to put clustering in jboss3, now I want to make
> jboss2.0 a
> REAL PRODUCT, that reaches the best on the market. So
> clustering, if you
> reread my TODO mail is #1 priority... IT WILL BE DONE.
>
> <theory and soap box>
> back to the TM distribution and extra-VM. Be aware that
> jboss2.0 already
> today does "distributed" transactions in VM in the sense that
> complex B2B
> calls with many many beans do take care of the transaction
> stuff. Check the
> testbeans and you will see we do lotahoops test on the
> transaction (and THAT
> is what we want to fully test). However in the order of priority of
> features in j2ee, i don't see the distributed tx real high.
> Right now I
> believe that 90% cases are taken care of with the
> *ultra-fast* TM manager
> that we have in. Rickard, Myself, and now Ole are actively working on
> making that a simple yet fast and powerful TM for ALL inVM
> needs (and some
> more). I don't see our constituency yelling "WE NEED
> DISTRIBUTED TX TODAY",
> for the simple reason that folks that REALLY use this usually
> are found at
> WebLogic/WebSphere (when WS works :). It is my belief, but maybe I am
> mistaken and feel free to correct me, that the TM in place is a "good
> enough" solution for the functional needs and a "better than enough"
> solution for speed :). Again if that is not the case, voice
> your opinion
> and *show* us an application you want to do manhana with the
> distributed Tx.
> I am not saying these don't exist, they do, all I am saying
> is show me the
> need *here and now*.
>
> Finally I do believe that people need to understand how to
> use distributed
> inVM component transactions (as we have today in jboss2.0)
> before we can
> move to distributed extraVM transactions.
>
> </theory and soap box>
>
>
> >
> > /Rickard
> >
> >
> >
> >
>
>
>
