I'm getting kind of tired of what I find vague complaints without detailed explanations of the framework in which you think there might be a problem.
I think remote AOP is going to need; 1. some representation of the object you are calling 2. client interceptors. For instance, to get the security context. 3. a transport mechanism 4. something on the other end of the transport mechanism to find the right target 5. server side interceptors If you disagree please explain in detail what you propose. Personally I think the AOP stuff should do this always, with a possible "null" transport mechanism, at least for "remotable" objects. If you agree, then I hope you will agree that there has to be some metadata on the client side to define the client interceptors and the transport. If there is some place to put metadata, why can't I use it for the tx support? I would like to note that my future plans for this involve method specific interceptor chains with a variety of "client side" and "server side" tx interceptors, each one performing half of the TxSupport work. No maps, just different specialized interceptors, with different interceptors per method depending on the tx support. I also think you will admit that even in aop you could have two interceptors even if both were on the server side: one to get the tx from the context if appropriate or remove it if appropriate, one to start a new tx if appropriate. On 2003.02.21 16:12 Bill Burke wrote: > I've been thinking and should have posted this before. Your design is > fataly flawed when I start applying it to the AOP framework. Your design > assumes that there is a proxy sitting in front of everything. In AOP > this > is not the case. If you look at > varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to > combine the clientInvoke and serverInvoke into one method because there > is > no proxy object between the application code and the object instance. You could have written two separate interceptors, one with the client invoke and one with the server invoke. > > Ok...no problem you say....Well, think of what happens when the app > developer decides to remote an AOP'd object. I will have to have 2 sets > of > interceptor chains and have to figure out whether the call is a remote > call > or local. Well, I guess I could insert a flag into the Invocation on > whether the call went through a proxy or not. Do you mean transport? I don't understand. But do you see where I'm > going? nope I don't think its a good design to rely on the client to handle > transaction semantics. I don't think its a good idea for the "server" to > have to rely on client logic unless it really has to. So serialization and RMI are a bad idea because they allow moving server logic to the client? In this case the transaction support HAS TO RELY ON THE CLIENT TRANSACTION MANAGER or there will be no dtm. I don't understand why you are getting your knickers in such a twist when I want to move some static data to the client to reduce complexity and comply with the industry standard dtm spec. david > > All and all, my gut tells me that the current client/tx design will cause > problems. I want interceptor designers in general to avoid this kind of > dependency. > > Bill > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of > David > > Jencks > > Sent: Wednesday, February 19, 2003 11:02 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is really really good > > > > > > On 2003.02.19 09:37 Bill Burke wrote: > > > > > > > > What you implemented is fine. My only problem with it is that I > > > > think it is more logical to let the server decide if it needs the > > > > tx, and that I think the registration callback could be avoided > > > > (with minimal redundant client side bookkeeping) even if the > > > > decision is made on the server side. > > > > > > > > I got the impression that this implementation would also be used > > > > in the other invokers, and that made me worry about CORBA > > > > interoperability. If this approach will not be used with the IIOP > > > > invoker, I have no problem with it. > > > > > > > > > > Yes this was my exact worry and still is. That we'll have to have a > > > different set of interceptors on the server side for different > > > transports. > > > This is unexceptable because we want each EJB to be able to > > listen to and > > > service calls from different transports at the same time. > > > > > > David, I'm not suggesting to redesign your code, but is the design > > > flexible > > > enough so that we could switch to a server-side based design? > Iteration > > > is > > > a fine thing.... > > > > I don't think we will have problems adapting my current design to use > > corba. Before we continue I think we should get a clear understanding > of > > what is supposed to happen when the corba tx policy and the j2ee > > tx support > > disagree. Does anyone know where this is described in specs? > > > > Basically the corba design says "if there is a transaction in the > context > > it must always be transmitted and imported on the server" whereas > > j2ee does > > not always need to import the tx. The purpose of the client side > > interceptor is to not generate tx branches that won't be used. I think > > that any reasonable corba implementation is going to follow corba > > semantics > > and always generate a transaction branch on the client for the > > remote call, > > since as far as the corba spec goes, if the call is made within a tx > the > > transaction will in fact be used on the server. > > > > In my view the heaviest part of the process is generating a tx branch > on > > the client: once it is generated, then it has to be prepared and/or > > committed. The communication overhead on these messages is > > likely to dwarf > > any other resource usage. > > > > The choices I can see here are: > > > > 1. only generate the branch if it is needed, but do it right > > away. This is > > what I implemented and I think it is simplest and the only one that is > > likely to be comprehensible when someone looks at it in a week or two. > > > > 2. Only generate the branch if it is needed but do it after the work is > > done. I think this is Ole's proposal. This introduces a lot of > > bookkeeping on the client to associate client side transactions to > > branches. I don't think I'd be able to maintain this code, in a week I > > wouldn't remember how it worked. After spending a day to figure it > out, > > I'd simplify it to (1). > > > > 3. Always generate a branch immediately, but have the xaresource return > > read-only on prepare if the tx did not need to be imported. This is > > unacceptable because it forces 2pc in the case that there is only > > one other > > branch. > > > > Don't we need a client side method-to-method-attributes map > > anyway for many > > other purposes such as determining if a return value can be cached? > > > > david > > > > > > > > Bill > > > > > > > > > > > > ------------------------------------------------------- > > > 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: 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: 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: 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
