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
