> > Agreed. In this case there is a strong performance reason to > split the > code into two interceptors:
The point is that the call in the interceptors is JUST dissaciation and 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. BUGS. marcf > > client 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 expensive > operations, > >>>> since the JTA spec version 1.0.1 (section 3.2.3) > requires the TM to > >>>> delist/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 and > comes from the > >>> name 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" "suspend > association" 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
