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. 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. 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
