> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David > Jencks > Sent: Monday, February 24, 2003 3:02 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing > since sliced bread > > > On 2003.02.24 14:35 Bill Burke wrote: > > > > > > > > > > Bill, what I find really boring and unpleasant about this > discussion is > > > that I can't find any evidence that you read most of my posts, or that > > you > > > > Ditto. > > > > I thought I did read your stuff and replied appropriately. Maybe I > > missed > > something. What I saw you propose for non-Java and I'll quote you: > > > > "outside world >>> something corba and proxy-like > ci1 > ci2 > > some kind > > of > > invoker-like thing > si1 > si2 > actual target object" > > > > My argument against this was that you would have to maintain 2 separate > > interceptor chains on the server. > > > > For IIOP the chain would be (as you stated) > > > > IIOPInvoker > ci1 > ci2 > si1 > si2 > actual target object. > > > > For RMI/Java the chain would be > > > > DP > ci1 > ci2 > ---- network --- JRMPInvoker > si1 > si2 > > > > I voiced a similar problem with AOP where the AOP interceptors > would have > > to > > know whether the call had traveled through a remote proxy object. > > I wrote the lengthy description/picture below in an attempt to find out > what you are talking about, since this argument doesn't make sense to me. > I didn't see any response from you about it. > > I'll try to explain why, specifically, your argument makes no sense to me. > > I think interceptors all implement required functionality. If > you put them > in the chain, it's for a reason: they are doing something you need. > Therefore, however many transport steps are in the middle, any invocation > should go through the same (target specific) interceptors. (IMO transport > layer interceptors on both ends are a good idea too, but that's a separate > argument). If the interceptor chains have different > interceptors, you will > get different behavior, and you should be getting that through other means > such as additional deployments. > > Therefore, for a conceptual interceptor chain of ci1 > ci2 > si1 > si2, > this might end up as > > ci1 > ci2 > ||transport from client machine to server || > si1 > si2 > > target object. > > or > > ci1 > ci2 > ||do nothing "transport" on same machine || > si1 > si2 > > target object. > > It might be possible to arrange for > > ci1 > ci2 > si1 > si2 > target object but I don't see why you'd want to > particularly. > > Furthermore, for corba, > > java-corba-endpoint on server > ci1 > ci2 > || possible "transport" > translation layer whose need is questionable || > si1 > si2 > target > object. >
What I"m saying is that you've created a need for this construct with the split in TxSupport of clientINvoke and serverInvoke. With your current design, ci1 needs the EJB's trans-attribute method map. Thus we need 2 different interceptor chains on the server to service IIOP and JRMP. With the current architecture this interceptor chain requirement wouldn't allow the same EJB target object to service calls from both IIOP and JRMP at the same time. You would have to create two separate EJBs with two different Container Configurations. Here's what it would look like in reality with an endpoint target object with id 1223 C++ Client -- network --- endpoint Invoker> MBean invoke > SERVER SIDE CHAIN: ci Tx > ci2 > si 1 > si 2 > 1223 Target Object Java client > DP > ci Tx > ci2 --- network -- Invoker > Mbean invoke > si1 > si2 > 1223 Target Object Look at the configuration in standardjboss.xml. The configuration for client and server side interceptors are separate. If you would configure the above example in XML you would see that you would be defining 2 separate chains and as a result, you would not be able to have the same Target object receive requests from 2 separate For JBoss 3.2 and 3.0. All the tx interceptor did was propagate the transaction. This interceptor is not needed for a C++ iiop client because the IIOP transport does the propagation for you. Thus you have no need to > To me these are all the same interceptor chain: they all have the same > members, with the exception of the one missing any kind of transport. The > chain has 2 entry points: ci1 and si1. If you regard this as > more than one > interceptor chain please explain your point of view. As I understand it, > this is also essentially how we handle ejbs today: certainly we maintain > both the client and server interceptor stacks on the server. > It is not the same chain. Do the actual XML configuration remembering that a C++ IIOP client does not have client-side interceptors. You will find that in no way will you be able to define configuration such that one target object can receive requests from multiple transports at the same time with the current architecture. Maybe we eventually need to have the ability to define 2 separate interceptor chains. 1 for transport/target object specific things and 1 for generic target objects. Or maybe we should define the whole client interceptor > transport > server interceptor chain as one block of configuration. The problem with implementing this is that it effects a lot of code and would be some serious work when there really is no added benefit. My whole point is that because of your tx split, we cannot support multiple transports per one target object with the current architecture. I know you'll say, "So let's change it". My answer: All this complication just to avoid propagating a TX for NotSupported and RequiresNew calls and because you're requiring DTM for every client(you're trying to avoid branch creation too, correct?). Our user base has been living with this "inefficiency" since UserTransactions were added to jboss. Hmmm... or maybe not? The branch creation would need to happen with every request, correct? Couldn't this be optimized instead? > It occurs to me that what you write is consistent with not having client > side interceptors for aop. Is this your plan? If so, how will you gather > the context information for the invocation? If not, why do you want to > put limits on what the client side interceptors can do? > TX and security are really CORE to JBoss, CORBA, really any distributed object framework. They should be written as simple as possible so that they can be easily ported to other languages and transport protocols. I want the ability to support multiple transports per target object. I don't want yet another fundamental architectural change. I want to avoid configuration bloat. IMHO, CORE client interceptors such as security and tx should be written such that if the client doesn't support interceptors (C++) you don't break the server side or put additional configuration requirements on the server side. Bill ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
