I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor.
Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke <[EMAIL PROTECTED]> wrote: > Ok, maybe I shouldn't have said "fatally flawed". > But again, my gut tells > me that it is bad to have a dependency between > server and client > interceptors if it is not absolutely needed. > > > -----Original Message----- > > From: > [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > Behalf Of Bill > > Burke > > Sent: Friday, February 21, 2003 4:12 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is > really really bad > > > > > > 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. > > > > 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. But > do you see where I'm > > going? 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. > > > > 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. === message truncated === __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ------------------------------------------------------- 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
