Per Bockman wrote:
>
> 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).
In fact we will run into these problems whenever a distributed (as
opposed to all-in-same-VM) federation of components is needed.
> 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.
I want IIOP support too, but I don't think we can do it in
time for the deadline.
A problem with a pure CORBA OTS implementation is that it will
not work when RMI-JRMP is used for the transport.
I do, however, not see why a proprietary TX-propagation solution
shouldn't be able to do the job.
I am currently speculating about how best to make a jBoss-proprietary
distributed TM that is modelled strictly after OTS, but that
will work with both RMI-JRMP and raw IIOP when this is supported.
While I don't think this is impossible, I am pretty sure that this
will not be finished (and definitely not stable) in five weeks.
> 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.
The EJB specification does not mandate a specific transport,
but I don't think a standard for service context propagation
has ever been added to JRMP.
So this leaves us with IIOP for cross-vendor interoperability.
> 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).
I expect this will be possible with a DTM modelled after OTS.
But for JRMP transports this will be jBoss-specific.
> 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).
The coordinator should wait for the resource invocations to return,
and if this times out or an exception is thrown we know that a resource
failed.
I think that 2PC is secure if the following assumptions are met:
A) Stable storage is really stable (ie. disks never crash).
We cannot get around that disk crash problem, but we can
get close by using disk mirroring and other techniques.
B) Timeouts are set to such high values that timeouts and
heuristic decisions never occur. In particular timeouts
should be longer than the longest possible downtime for
the network. In real life this is bad as uncommitted
resources may hold locks that keep other clients out
until a timeout occurs. In practice is it desirable to
set reasonable timeouts, and fortunately OTS allows
for heuristic decisions the be thrown and mandates that
resources should not forget about the heuristic until
explicitly asked to do so. This means that the server
managers can look into the heuristic and possibly change
it (using proprietary interfaces). But of course any
heuristic decision is a potential violation of the ACID
properties.
C) There are no bugs in the transaction manager or the resource
managers. In real life this is near impossible.
> 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:-)
This is my opinion too, but unfortunately this leaves
JRMP out in the cold.
Best Regards,
Ole Husgaard.
