David Jencks wrote:
Thank you for your explanation, David. I’ve looked into the code and have few more questions, if you do not mind.On Sunday, January 19, 2003, at 10:00 AM, Igor Fedorenko wrote:David Jencks wrote:Can you describe this "basic stuff" a little? I am considering implementing distributed tx. I looked into the code and I have some implementation ideas in mind, but I would like to know what is your plan here and I definitely do not want to repeat something that is already done.On Thursday, January 16, 2003, at 09:10 AM, Barlow, Dustin wrote:Let me simplify the example to demonstrate my real point. (and hopefullythe only reason is that no one has previously written a distributed tx manager. I wrote the basic stuff we need in jboss 4, it should even work with the trunk invoker.
this is a better example)
In the 3.x series of JBoss, there isn't a way to have one SSB with a
transaction attribute of Required call another SSB with a transaction
attribute of Required on a second jboss instance and have both of those
beans enlist in any kind of "native" JBoss transaction. If you stay within
one instance of JBoss, you are fine, but the moment you start to really do
n-tier designs with tight transaction integration (ie XA), that is when
problems arise with this NotSerializable exception. I do know that the 3.x
series only supports local transaction, but my overall point is that I just
don't understand why a distributed transaction has not been a "native"
feature of JBoss from the beginning being that it seems to me that it would
be fundamental to n-tier designs. I presume there is a good reason for
this. I just don't know/see what that reason would be.
So far it is only implemented for the trunk invoker, the others will be similar but I'm pressed for time and waiting for the AOP situation to clarify a bit.
The invoker basically exposes itself to the "client" transaction manager as an XAResource, thus getting an xid branch for the tx on the remote server machine. This xid is transmitted in the invocation object, and imported into the remote server tm as a transaction, keeping the original global id part. remote server branches are created as usual. Then on prepare/commit, the xid is again transmitted using an invocation object, and finishes the remote branch using the XATerminator interface required by the jca 1.5 spec.
So far I have only tested it a bit with UserTransactions, which now have a semi-functional tx manager on the client to provide xids. The next thing to do is to actually set up 2 servers and test whether it works. After it does, then I'll extend it to the other invokers.
Nothing seems to guarantee uniqueness of branch ids in parent and child transactions. Both of them start from the same branch id (zero) and thus generate same Xids. Entire Xid should be propagated to a remote node, and branch id should be generated by upending additional digits (resulting branch id will look something like "parentBranch/subordinateBranch").
How do you deal with loops? For example, node A starts a transaction, calls node B which calls node A back. From what I see, transactions on the two nodes will cross-reference each other making calls to commit/rollback deadlock. There is another flavour of this problem – node A calls node C, then calls node B which calls node C. As a result, transaction on node C will be prepared/committed/rolledback twice. Ideally, only new subordinate transactions should be enlisted into a parent, in other words if a transaction re-enters a node nothing should be enlisted to make sure there are no loops.
Subordinate transaction gets started regardless whether it is actually used on remote node or not. For example, if node A calls into "transaction=RequiresNew" method on node B an empty subordinate tx will be started causing unnecessary network traffic at commit time.
Is there anything that prevents calling "commit" on subordinate transactions? Not a big deal, just for completeness sake ;-)
And, finally, why did you tightly couple distributed tx logic with invoker’s implementation? Why is not it possible to write an interceptor that does distributed tx stuff that you’ve described but in invoker independent way?
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.com
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
