On Tuesday, January 28, 2003, at 10:07 AM, marc fleury wrote:
We already agreed with you that in one vm association/dissociation are essentially free and if they aren't it is a bug. I'm saying that importing a tx when you don't need to is NOT free and if we avoid it the code will become easier to understand. Although "easy to understand" is definitely subjective I have also found myself confused by the current code in the server side tx interceptor.The point is that the call in the interceptors is JUST dissaciation andAgreed. In this case there is a strong performance reason to split the code into two interceptors:
association. The mumbo jumbo we are talking about (whatever it means to
suspend and resume a transaction) is not really relevant to the
interceptor. I don't think we need to change the interceptor just the
fact that suspend/resume should not be distributed calls just
"association" calls in JTA. Let's treat spec bugs for what they are.
david
BUGS.marcfclient tx interceptor attaches the tx to the invocation only if the tx is going to be used (requires, supports and there is a tx). For requires new it removes the tx if attached [ (for remote invoker only) invoker xaresource converts tx if it exists into an xid -----transport --- xid is used to start/identify tx on other jboss instance ONLY IF PRESENT ] server tx interceptor creates new tx if required and not present. Now each interceptor is very clear about its responsiblitly. Furthermore, the tx is NOTimported into the 2nd jboss vm if it can be determined that it won't be doing any work there. This saves one or two remote calls during commit. david-dain On Monday, January 27, 2003, at 05:40 PM, David Jencks wrote:FWIW, I agree 100% with you on this marc david jencks On Monday, January 27, 2003, at 05:34 PM, marc fleury wrote:In all of the other application servers I have been working on TransactionManager.resume() and suspend() are expensiveoperations,since the JTA spec version 1.0.1 (section 3.2.3)requires the TM todelist/enlist every resource that takes part in the transaction, which is costly. If it is done differently in Jboss on purpose,IT IS A BUG IN THE SPEC !!!!! I am dead serious. Also all the discussion sucks andcomes from thename of the API. Suspend() and resume() look like they are Tx lifecycle operations which require resource delisting???NO NO NO,resume and suspend in the scope of what we do in the method is PURELY THREAD ASSOCIATION, the TX goes on. In our code it means "resume association" "suspendassociation" not"suspend TX". I had called it "dissassociateThread()" and"associateThread()" to<emph> the fact that all we are looking for is "association of thread to TX" and THAT'S IT. It was changed in subsequent impls. You are talking about something else, you are talking about the notion of "suspending THE TRANSACTION". Do we have a line? marcf "Doesn't anyone else see this? I feel like I am taking crazy pills" -- ZooLander -- ------------------------------------------------------- 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------------------------------------------------------- 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------------------------------------------------------- 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
