I don't know which version of Tyrex you are referring to here, when I worked with it, all distributed 2pc was implemented. (I was using 0.9.8) And distributed transactions worked properly.
That is easy. SPEED. Distributed transaction are pricey and difficult.
By choice we did "fastTM" as an InVM implementation. Typical case of
90/10. Most applications actually use only invm stuff and so having an
implemetnation that serializes stuff back and forth isn't worth it.
Right now FastTM is REALLY FAST, so that the overhead of synchronization
is NIL (dozen or so native java method calls). It is one of these things
where we said "you really need DTM, write it or use tyrex". Turns out
Tyrex was a fake with critical methods throwing NotImplementException.
But clearly we didn't BASE the design on distribution.
The reason Tyrex no longer works with JBoss 3.x is because currently, the invoker code is not calling the TM to provide it with the TPC, just tries to serialize the transaction object itself. In order to get Tyrex to work again, I would have to wrap each Tyrex Transaction object with a special (Externalizable) wrapper that would serialize itself by extracting a TPC and sending only that down the wire. On the remote end the wrapper would be unmarshalled and during unmarshalling it would try to register the local TM as subordinate with the originating TM. This is doable but imposes a wrapper for each tx instance. I remember discussion about this and how Ole was not happy about it. Where are you Ole?
It seems to me, the real issue with the inability to efficiently integrate an arbitrary JTS-compliant DTM with JBoss (like Tyrex), is lack of well-defined TM-independent transaction propagation semantics withing invoker layer. Another thing that would help tremendously is call-back to the originating server in the invokers. Not only it would simplify integration, it would enable some neat optimizations. Here is what I mean.
For initial integration of Tyrex I had to start an RMI server for TM (well, actually for each distributed TX, don't ask why, I did not understand much when I wrote it, but it worked :) ), which would get called by the recipient of the invocation to register as subordinate XAResource passing to the originator it's own RMI stub through which the originator would call prepare(), commit() or rollback(). This resulted in an additional network trip for registration and each of the subsequent communication between the participating TMs. Nothing prevents a very simple optimization of doing at least the registration on the return trip from the invocation.
Ideally, the invocation pipe through which the invocation arrived to the second server should supply a Callback interface to the originating (MBean?) server and implementations of this callback interface could optimize callback invocations, like bursting, etc. I guess this is somewhat similar to how XmlBlaster does asynch communication -- messages that flow in opposite directions can use completely different transports (e.g. an original subscription request came through a socket but requested updates to be returned through XML-RPC due to firewall restrictions). I've seen some of the need for this in the forums on Invokers.
Am I making sense?
Anatoly.
-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
