On 2003.02.24 15:16 Igor Fedorenko wrote: > David, > > Can you remind me how you are going to deal with possible loops in > transaction tree. > > Consider this scenario: node A starts a transaction, does some work and > calls node B. Node B does some more work and calls node A back. There is > no way node B can know if the transaction has visited node A or not, and > if I understood your design correctly node B will enlist node A into the > transaction and create a loop.
yes. I don't really see any alternative. B has to send A some indication of what transaction the work should be done in, and A has to be able to send back some indication that the work failed, tx is marked for rollback. Of course, this is no big deal, all you > have to do is to write TransactionImpl to re-entrant and make sure that > TransactionImpl.prepare returns "read-only" if the transaction is already > being prepared. I guess one part of this is that the tx import should recognize if there is already a branch of the tx on the machine, and use the original import/original tx. I'll have to review to see if this is what happens. Thanks david > > Thanks in advance. > > > > > -----Original Message----- > > From: David Jencks [mailto:[EMAIL PROTECTED] > > Sent: Monday, February 24, 2003 2:11 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing > > since sliced bread > > > > > > Bill, what I find really boring and unpleasant about this > > discussion is > > that I can't find any evidence that you read most of my > > posts, or that you > > remember the reasons for my design decisions for more than > > about 5 minutes. > > I've written fairly detailed explanations of my views of > > both interceptor > > architecture and corba integration and asked for comments or > > whether you > > agree or disagree. I haven't seen any direct responses. > > > > At this point I don't want to read the same argument from you again. > > Please implement your idea for how dtm will work so we can discuss > > something concrete. > > > > thanks > > david > > > > > > On 2003.02.24 13:37 Bill Burke wrote: > > > Sure. The TxSupport class is a nice change and makes the > > code much more > > > readable. I have stated this before. But.... > > > > > > Merge TxSupport.clientInvoke and serverInvoke into one > > method. Remove > > > all > > > logic from client interceptor except TX propagation. > > Propagate the TX > > > always. Again, my reasoning is to isolate the EJB > > container from the > > > transport mechanism. Currently, in 3.2, you can invoke on > > an EJB from > > > any > > > protocol at the same time. With David's change, non-Java > > clients that > > > support TX propagation would require that > > TxSupport.clientInvoke be run > > > on > > > the server thus requiring us to have transport specific server-sdie > > > interceptor chains and a change to the current > > architecture. I think > > > that > > > this creates further complication in the server-side > > architecture and > > > will > > > further bloat configuration. All just to save a tx propagation for > > > NotSupported and RequiresNew methods. > > > > > > Or are you talking about the AOP stuff? Well, it is > > implemented, I do > > > have > > > an API. I have written the AOP Tx interceptor and it is > > tested within > > > the > > > testsuite. I am working on the Security one. So far, my > > design seems to > > > fit. The real test will be with the persistence metadata > > since this is > > > much more complicated. I've made an attempt to explain my > > design with > > > the > > > bootcamp slides and the crappy documentation I put together on the > > > website > > > /developers/projects/jboss/aop.jsp. > > > > > > > > > Bill > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] > > Behalf Of Dain > > > > Sundstrom > > > > Sent: Monday, February 24, 2003 12:36 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [JBoss-dev] TxInterceptor split is still the > > best thing > > > > since sliced bread > > > > > > > > > > > > Bill, > > > > > > > > Where is you design? David's design looks totally > > obvious to me. It > > > > is well understood, and based on our existing > > "real-world" experiences. > > > > To me it looks like you are the one invent "the perfect > > design/API". > > > > So can you present you invocation chain as did and show > > us the error in > > > > our logic? > > > > > > > > -dain > > > > > > > > On Monday, February 24, 2003, at 09:39 AM, Bill Burke wrote: > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: [EMAIL PROTECTED] > > > > >> > > [mailto:[EMAIL PROTECTED] Behalf Of > > > > >> David > > > > >> Jencks > > > > >> Sent: Saturday, February 22, 2003 11:48 AM > > > > >> To: [EMAIL PROTECTED] > > > > >> Subject: RE: [JBoss-dev] TxInterceptor split is still > > the best thing > > > > >> since sliced bread > > > > >> > > > > >> > > > > >> This is really boring and unpleasant, bill. We don't seem to > > > > > > > > > > I am sorry I am boring you. Summarized, my major > > concern with the TX > > > > > refactor is that it will not work for clients that cannot have > > > > > interceptor > > > > > chains (i.e. non-Java), but support Tx propagation > > (CORBA) for all > > > > > trans-attributes (specifically, NotSupported, and > > RequiresNew). I > > > > > thought > > > > > Marc's vision for creating these generic, transport > > specific invokers > > > > > was to > > > > > isolate the EJB Container from the transport layer, and > > I see this > > > > > refactor > > > > > as breaking this vision. > > > > > > > > > > The only way I see this working is if we have separate > > > > > transport-specific > > > > > interceptor chains on the server to support non-Java clients. I > > > > > wanted to > > > > > avoid this because this is what has happened when I put > > in support > > > for > > > > > multiple invokers. Client-side interceptor configuration became > > > > > bloated. > > > > > All this to avoid creating and passing over a TxId. > > See my point > > > now? > > > > > > > > > > =========================== > > > > > > > > > > As far as AOP goes, I'm hoping that as we implement > > services on top > > > of > > > > > the > > > > > Framework and apply the framework to JMX and remoting, the > > > > > requirements and > > > > > API will be fleshed out as we iterate. I'd like the > > design of AOP to > > > > > be > > > > > driven by "real-world" requirements and applications > > rather than what > > > > > we > > > > > might think as the perfect (and probably bloated) > > design/API might be > > > > > currently. I'm not afraid of throwing code out or > > having to modify > > > > > huge > > > > > amounts of code to iterate. Iteration is key. Allows > > us to get to > > > > > market > > > > > quick and to quickly notice bad designs. Didn't somebody say > > > "Release > > > > > early, release often"? > > > > > > > > > > Bill > > > > > > > > > > > > > > >> have a shared > > > > >> understanding of how interceptors ought to work with local and > > > remote > > > > >> calls. Most of your comments make no sense to me, and I think > > > > >> contrariwise. I'll try to explain my view one more time, and > > > > >> I'll write an > > > > >> interceptor framework that satisfies my understanding > > of what is > > > > >> needed for > > > > >> mbeans, ejbs, remoting, and aop (which I don't > > understand all that > > > > >> well). > > > > >> If you don't like it and I can't understand your > > objections, I'll > > > let > > > > >> you > > > > >> indulge your previously expressed wish to write a transaction > > > > >> manager. You > > > > >> might also get that wish fulfilled if you say the following is > > > > >> obvious. I > > > > >> thought it was, but I don't think we have agreed on > > it. I'm writing > > > > >> it > > > > >> down to try to form a basis for discussion, which is currently > > > > >> missing. > > > > >> > > > > >> ========================== > > > > >> > > > > >> Dave's mental model for invocations. > > > > >> > > > > >> Lets assume first you already have something > > representing the object > > > > >> you > > > > >> are interested in (such as an ejb Remote interface > > object, mbean > > > > >> thingy, > > > > >> aop-ized object, or some kind of proxy). Items marked with a * > > > might > > > > >> be > > > > >> removed for non-remotable objects. > > > > >> > > > > >> Key to symbols: > > > > >> > > > > >> \/ interceptor chain "invokeNext()" calls. > > > > >> > > > > >> > > > > >> \/ > > > > >> || method/field access/... calls whose nature may vary > > > > >> depending on the > > > > >> application and that are not part of the > > interceptor/invocation > > > > >> framework. > > > > >> > > > > >> \/ > > > > >> \/ calls between "segments". These are of the form > > > > >> invoke(invocation) > > > > >> on a particular object found by the current interceptor. > > > > >> > > > > >> .......... sequence of interceptors in a chain. > > > > >> > > > > >> || > > > > >> || transport mechanism. For a remote object, this is the > > > > >> boundary > > > > >> between client and server. > > > > >> > > > > >> > > > > >> =========================== > > > > >> > > > > >> > > > > >> Some program does something on the "object" > > > > >> > > > > >> \/ > > > > >> || > > > > >> > > > > >> The Object > > > > >> > > > > >> \/ > > > > >> || > > > > >> > > > > >> Something that knows about interceptor chains and metadata. It > > > looks > > > > >> at > > > > >> the method (or field access, ...) call and its environment and > > > > >> determines > > > > >> what interceptor chain to use. It constructs an > > Invocation object > > > > >> that > > > > >> includes an iterator over the selected chain, the > > method call data, > > > > >> and > > > > >> some metadata. Then it starts the invocation down the > > chain. I > > > will > > > > >> call > > > > >> this a Container. I believe it corresponds to your > > aop Advisor(s). > > > > >> > > > > >> \/ > > > > >> > > > > >> Several interceptors (client side interceptors specific to the > > > > >> object/class you are calling) > > > > >> > > > > >> ..... > > > > >> > > > > >> \/ > > > > >> > > > > >> * Transport selector interceptor. This examines the > > metadata and > > > > >> picks a > > > > >> transport endpoint. It calls invoke(invocation) on > > the selected > > > > >> transport > > > > >> endpoint. It does not call invocation.invokeNext(), so > > this may be > > > > >> the end > > > > >> of the use of the original interceptor iterator. > > > > >> > > > > >> \/ > > > > >> \/ > > > > >> > > > > >> * Transport endpoint. If this is a local "do nothing" > > transport, > > > it > > > > >> may > > > > >> simply call invocation.invokeNext(). Otherwise, it > > replaces the > > > > >> interceptor iterator with one for the client side transport > > > > >> interceptor > > > > >> stack. > > > > >> > > > > >> \/ > > > > >> > > > > >> * Several interceptors (client side interceptors > > specific to the > > > > >> transport > > > > >> endpoint you are calling. Examples would include the > > XAResource > > > > >> representing a remote jboss instance (whenever the branch is > > > created, > > > > >> you > > > > >> still need an XAResource, and it needs to know about the method > > > > >> calls), and > > > > >> the clustering thingy that picks a remote server) > > > > >> > > > > >> \/ > > > > >> > > > > >> * client side end of the transport. I believe this is > > essentially > > > the > > > > >> remoting framework. > > > > >> || > > > > >> || > > > > >> || > > > > >> * server side end of the transport. This may include > > some kind of > > > > >> relationship with a thread pool. Lets assume the work is > > > > >> dispatched with a > > > > >> thread, no matter how it is picked and how > > > > >> synchronous/asynchronous it is. > > > > >> Anyway, the reconstituted invocation object has its interceptor > > > > >> iterator > > > > >> replaced with one for the transport specific server side > > > interceptors > > > > >> > > > > >> \/ > > > > >> > > > > >> * Several interceptors (server side interceptors > > specific to the > > > > >> transport. In my current dtm implementation, one of > > these would > > > > >> import an > > > > >> xid in the invocation into the server side tm) > > > > >> > > > > >> ..... > > > > >> > > > > >> * Target selector. Based on the metadata, this > > interceptor picks > > > and > > > > >> locates a target object, and calls invoke(invocation) > > on it. This > > > is > > > > >> the > > > > >> end of the transport specific server side interceptor chain. > > > > >> > > > > >> \/ > > > > >> \/ > > > > >> > > > > >> * Server side target object. This is analogous to the current > > > > >> server side > > > > >> ejb Container object. It replaces the invocation's interceptor > > > > >> iterator > > > > >> and starts it off by calling invocation.invokeNext(). > > > > >> > > > > >> \/ > > > > >> > > > > >> Server side interceptors. For non remotable objects > > and for "no > > > > >> transport" > > > > >> local remotable objects, the original interceptor chain would > > > continue > > > > >> here. > > > > >> > > > > >> ....... > > > > >> > > > > >> \/ > > > > >> > > > > >> Final interceptor. This uses the metadata and the method > > > > >> information to do > > > > >> something to the actual object instance we are working with. > > > > >> > > > > >> \/ > > > > >> || > > > > >> > > > > >> object of interest. > > > > >> > > > > >> > > > > >> > > > > >> Note that this requires, for remotable objects, being > > able to get > > > two > > > > >> interceptor iterators: one for the client side > > iterators, and one > > > for > > > > >> the > > > > >> server side iterators. For "local only" objects, you > > only need one > > > > >> interceptor iterator. For objects that can be local or remote, > > > > >> looking up > > > > >> the server side target object can be avoided if the client side > > > > >> interceptor > > > > >> iterator also includes all the server side > > interceptors: the (client > > > > >> side) > > > > >> Transport Endpoint would (after determining that the > > call is local) > > > > >> simply > > > > >> call invokeNext() on the invocation. > > > > >> > > > > >> > > > > >> Lets see if we can come to an agreement on this much before we > > > > >> consider > > > > >> constructors or how to get something representing a > > remote object. > > > > >> > > > > >> Please remember that I consider this very obvious, but I don't > > > think > > > > >> we > > > > >> agree on it: I think if we did your comments would > > make sense to > > > > >> me, and so > > > > >> far they don't. Saying something like "don't be obvious" will > > > > >> indicate to > > > > >> me that you are not interested in discussing this > > aspect of jboss > > > > >> architecture with me, so I will take your > > recommendation and stop > > > > >> working > > > > >> with interceptors, at least until my curiousity gets > > the better of > > > my > > > > >> sense. > > > > >> > > > > >> david > > > > >> > > > > >> > > > > >> ------------------------------------------------------- > > > > >> This SF.net email is sponsored by: SlickEdit Inc. > > Develop an edge. > > > > >> The most comprehensive and flexible code editor you can use. > > > > >> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day > > > Trial. > > > > >> www.slickedit.com/sourceforge > > > > >> _______________________________________________ > > > > >> 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 > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > 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 > > > > > > > > > > > > ------------------------------------------------------- > > 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 > > ------------------------------------------------------- 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
