> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Jeff > Haynie > Sent: Friday, February 21, 2003 6:15 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is really really bad > > > Yes - but you guys don't seem to buy into it otherwise you won't be > talking about where and how tx or remoting should go into AOP. > > Maybe I'm missing something. >
I'm not understanding you. I certainly buy into it and am implementing stuff (albeit slowly). Whether you and David buy into it is irrelevent. The vision is set. THis is where we're going. The whole point is isolation and being able to dynamically remote or not remote with any protocol you want. IMHO, Davids implementation for tx right now doesn't allow for this isolation. He disagrees. So what? We disagree. Eventually it will all flush out and either David and/or I will end up rewriting everything. My bet David gets there first since I've got A.D.D. Bill > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bill > Burke > Sent: Friday, February 21, 2003 6:09 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is really really bad > > > > > > I personally don't think AOP should have anything related to > > transactions, remoting, etc. I think that should be pushed up into the > > > functional areas that apply those specific semantics to the subsystems > > > since they are quite different depending on the subsystem (JMS, EJB, > > etc) and location (local,remote). > > > > Where have you been? Marc has been talking about creating an AOP > framework and services on top of this framework since the fall. The > whole point is to break ourselves away from EJB and isolate and abstract > out distribution infrastructure even more from a coding perspective. > > Bill > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Hiram Chirino > > Sent: Friday, February 21, 2003 5:17 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is really really bad > > > > > > > > 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 > > > > > > > > > > ------------------------------------------------------- > > 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
