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