<snip>
Thank you for your explanation, David. I’ve looked into the code and have few more questions, if you do not mind.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.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.
Thanks for the review, I greatly appreciate it.
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").
I thought I had implemented that, I will have to look again.
Well, I think you always have to enlist all the branches into the tx so the xid will transmit properly for the actual work, but you are right about the loops. I think if the parent sends xids of the form
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.
original globalID
thisparentID/branchnumber
the child can use the thisparentid part to determine if the branch in the child came originally from this parent, and return this info in the return value. The parent can use this to decide whether to commit/rollback on this branch.
I want to solve this by splitting the txInterceptor functionality differently between the client and server interceptors. I want the client interceptor to only attach the tx to the invocation for supports and requires (and throw exception if appropriate, without remote call). The server tx interceptor will only deal with adding the new tx for requires and requires new. Thus the tx will be transmitted only when necessary.
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 ;-)
good point, should be pretty easy to fix.
That's my plan, and I've discussed doing this in an interceptor once or twice in mailing lists, what is there for trunk invoker is only a prototype. I'm waiting for a little more time to work on this and for the aop stuff to be a little more clear.
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?
thanks
david
-- 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
------------------------------------------------------- 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
