> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Jeff > Haynie > Sent: Friday, February 21, 2003 7:02 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is really really bad > > > Oh, I buy into it - and I'm neither for OR against what David is > saying. I'm merely saying you should separate the concerns - but it > seems like that is obvious and redudant (although not so apparent with > all the back in forth) to you. > > As you know, I don't work for Jboss Group. I'm just merely trying to > help out on my own *free time* and try and help make this a better > product with what little value I can add. >
As Dain said, just ignore flames and don't let them deter you from entering the conversation. (Yes I flamed you, and no, I'm not sorry. But I'd still go out for beers if you're still coming to Boston.) > Sorry I stepped into the flames. I was hoping to enlighten a little bit > to the fact that you could push some of this stuff into the remoting > stuff that tom and I worked on. > Tx propagation can be pushed to a generic remoting framework/object if the underlying transport supports it. Class/Interface Metadata can't. Bill > Jeff > > > > -----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 > > > > > ------------------------------------------------------- > 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
