I don't see where the tm.resume happens to associate the transaction with the current thread. The old UserTransaction stuff is still there in JRMPInvokerProxy and JRMPInvoker (importTPC and such), but the logic to associate the thread on the server with the transaction is not there anymore unless it is hidden someplace.
Bill > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Hiram > Chirino > Sent: Wednesday, February 12, 2003 7:31 PM > To: [EMAIL PROTECTED] > Cc: David Jencks > Subject: RE: [JBoss-dev] TxInterceptor split is bad AND broken? > > > The transaction is not getting propagated across the > wire. A new XID is what is getting propagated. > Remember that an XID != the tx. The relationship is > that a tx will have multiple XIDs (one ore each > resource that is involved in the tx). > > David is treating the remote jboss server like any > other transacted resource. He enists the XAResource > of the remote server, and gives that XAResource a new > XID. > > Since remote tm is providing an XAResource interface > to the remote tx, the local tm can commit/rollback the > remote tx via a 2pc. > > David, I hope that was accurate since I have not > really looked at your code! > > Regards, > Hiram > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > Ok, I'm looking at the code further and I'm pretty > > confused on how a > > Transaction get propagated across the wire now. Can > > you explain? I don't > > see any code anywhere that is doing a tm.resume from > > the transaction that is > > past across the wire. Is this code broken? > > > > Bill > > > > > > > -----Original Message----- > > > From: Bill Burke [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, February 12, 2003 5:51 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] TxInterceptor split is > > bad > > > > > > > > > Another thing David, > > > > > > I don't see you always stuffing the Transaction > > into the > > > invocation object. A few interceptors rely on the > > transaction > > > being in the invocation object. Any objects to > > fixing this? > > > > > > Bill > > > > > > > -----Original Message----- > > > > From: > > [EMAIL PROTECTED] > > > > > > > [mailto:[EMAIL PROTECTED]]On > > Behalf Of Bill > > > > Burke > > > > Sent: Wednesday, February 12, 2003 5:36 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [JBoss-dev] TxInterceptor split is > > bad > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: > > [EMAIL PROTECTED] > > > > > > > > [mailto:[EMAIL PROTECTED]]On > > > Behalf Of Hiram > > > > > Chirino > > > > > Sent: Wednesday, February 12, 2003 5:09 PM > > > > > To: [EMAIL PROTECTED]; > > David Jencks > > > > > Subject: Re: [JBoss-dev] TxInterceptor split > > is bad > > > > > > > > > > > > > > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > > > > > What if you don't have java on the client > > side? > > > > > > What if you're CORBA with > > > > > > OTS? You're making it harder for > > Non-JBoss/Java > > > > > > clients to integrated with > > > > > > us. I think this split should be undone. > > > > > > > > > > > > > > > > How des OTS work? The corba guys tackled the > > DTM > > > > > problem too right?? > > > > > > > > > > > > > They have the concept of a ThreadLocal (Current) > > (My knowledge > > > > is probably > > > > outdated and foggy). In O2K the client side > > interceptor stuffs > > > the value > > > > from the transaction current into the IIOP > > service context, > > > much the same > > > > way we used to do before David's switch. > > > > > > > > -1 for refactor > > > > > > > > > > BTW, why the split besides code readability? > > Is the > > > > > > DTM dependent on this > > > > > > at all? Is the TM even accessed on the > > client side? > > > > > > > > > > > > > > > > I think so. In the case were a client is a > > server the > > > > > local TM is accessed to treat the remote TM > > like a > > > > > XAResource. > > > > > > > > > > > > > +1 for refactor > > > > > > > > > > Another problem I see is that the TxMethod > > map is > > > > > > required on the client > > > > > > side as well. Makes proxies even more heavy > > and > > > > > > what do you do about a hot > > > > > > deploy? > > > > > > > > > > > > > > > > Yes.. but same argument could be made against > > any > > > > > client side interceptor we create. The proxy > > on the > > > > > client goes stale if a redeploy changes the > > proxy > > > > > config. > > > > > > > > > > > > > Ok, you're right. +2 for refactor > > > > > > > > > > Seems to me this is a bad idea. > > > > > > > > > > > > > > > > I agree it is a complex solution. But the DTM > > problem > > > > > is complex too. Any simpler sugestions?? > > > > > > > > > > > > > Actually the code is much more readable. I > > guess my only concern now is > > > > non-java/jboss clients. And, do we care? > > > > > > > > Another thing about this is that you're > > requiring the client to become > > > > beafier and beafier. I've been kinda nervous > > about the whole JMX on the > > > > client sort of thing and the start of deploying > > services on the > > > > client side. > > > > But maybe it doesn't matter. > > > > > > > > Bill > > > > > > > > P.S. Good to see you around again Hiram. > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This sf.net email is sponsored by:ThinkGeek > > > > Welcome to geek heaven. > > > > http://thinkgeek.com/sf > > > > _______________________________________________ > > > > Jboss-development mailing list > > > > [EMAIL PROTECTED] > > > > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Shopping - Send Flowers for Valentine's Day > http://shopping.yahoo.com > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
