> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of David
> Jencks
> Sent: Friday, February 21, 2003 9:26 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing
> since sliced bread
>
>
> On 2003.02.21 18:58 Bill Burke wrote:
> >
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] Behalf Of
> > Hiram
> > > Chirino
> > > Sent: Friday, February 21, 2003 6:44 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: [JBoss-dev] TxInterceptor split is really really bad
> > >
> > >
> > >
> > > --- Bill Burke <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > >
> > > > > I would like to note that my future plans for this
> > > > involve method specific
> > > > > interceptor chains with a variety of "client side"
> > > > and "server side" tx
> > > > > interceptors, each one performing half of the
> > > > TxSupport work. No maps,
> > > > > just different specialized interceptors, with
> > > > different interceptors per
> > > > > method depending on the tx support.
> > > > >
> > > >
> > > > Hmmmm...thanks for mentioning this. The AOP
> > > > framework will have to change
> > > > to support his type of per method intercepiton.
> > > >
> > > > Currently the ClassAdvisor asks the
> > > > InterceptorFactory for an instance of an
> > > > Interceptor and adds it to the interceptor chain.
> > > > For what you want to do,
> > > > this will have to change. The InterceptorFactory
> > > > should be responsible for
> > > > adding interceptors to the chain. Otherwise, my
> > > > isolation and separation of
> > > > metadata, interceptors, and pointcuts will be
> > > > broken.
> > > >
> > >
> > > I don't think that you model would be too broken.
> > > His interceptors should only hav to implement the
> > > org.jboss.aop.InvocationFilterInterceptor interface:
> > > boolean intercepts(Invocation invocation);
> > >
> > > The org.jboss.aop.Invocation.invokeNext() will skip
> > > over interceptors that do not interested the
> > > invocation. Currently invokeNext() interogates the
> > > intercetors on every invocation, but I think that we
> > > should be able to keep a per Invocation interceptor
> > > stack cache so that we can skip the interogation after
> > > the first method call.
>
> Per method interceptor stacks will eliminate the need to the interceptor
> filter interface.
>
Implementation detail. Who cares.
> > >
> >
> > That's not the issue. The issue is configuration. He wants to avoid
> > sending over metadata about the method/tx bindings.
> WTF???
>
> I want to send to the client the information about whether an exising tx
> needs to be sent, and as I have indicated I would like to encode this in
> which interceptor is in each method's client side invocation chain. Until
> we have method specific interceptor chains, I need a method to tx support
> map.
>
Actually I thought of another reason why having a per method interceptor for
TX is bad. You wouldn't be able to override the behavior at runtime. One
of the goals I have for the AOP framework and JBOss in general is the
ability to override behavior for one and only one method call. Maybe you
want to programatically decide transaction boundaries for a method call.
But anyways.....you raise a good point that I haven't thought of even though
I think per method interceptor for TX is a bad idea.
In AOP I want the definition of class metadata and interceptions(pointcuts)
to remain isolated. Currently the ClassAdvisor asks the interceptor factory
for an instance of an interceptor and adds it to the chain. I need to
switch this around so that the factory has control on how interceptors get
attached to the chain instead. This is so I can define chains easily for a
whole range of classes :
<interceptor-pointcut name="j2ee" class="com.*">
<interceptors>
<interceptor factory="Tx" .../>
<interceptor factory="Security..." ... />
</interceptors>
</interceptor-poincut>
Yet, be able to have per method interceptor stacks for a particular
interceptor type by letting the factory handle how interceptor(s) get
attached to the Class. Am I making sense? Yes? good, No? Doesn't matter,
implementation detail....
>
>
> TO do this he
> > creates a
> > Mandatory.java class and attaches it to the method. You see now?
> >
> > Actually David, you actually have almost the same memory footprint.
>
> As what???
>
> > WIthout
> > per method , you have one instance of the Tx interceptor.
> WIth, you have
> > an
> > instance per interceptor. Almost the same as a hashmap of methodnames
> > and
> > strings identifying the tx attribute.
>
> yes, this is obvious.
>
>
> Maybe we have really different ideas about what will go in the interceptor
> stack for an aop object. I was assuming that it would go like this, just
> like an ejb:
>
>
> local aop object > ci1 > ci2 > "local invoker" > si1 > si2 > si2 > actual
> aop object
>
>
Remember what we're trying to do here.
MyObject obj = new MyObject(...);
obj.doSomeMethod();
construction is intercepted
doSomeMethod is intercepted.
To have a "local invoker" new MyObject(...) would have to create a
non-dynamic proxy with MyObject. The is unacceptable because then we have
to define a contract for doing AOP when our goal is to avoid as much as
possible a contract. For example, we would have to construct the "proxy"
object using the same constructor, or require the Class implementor to
provide an empty parametered constructor. Also, all inlined field
initializations are just plain overhead for the "proxy" object and who
knows, might break their application. Basically what I'm saying is a proxy
is restrictive to the app developer because they will have to know that
their class is being intercepted and the contract we have defined for AOP
and the class.
>
>
> remote aop object > ci1 > ci2 > real invoker (transport) > si1 > si2 >
> actual aop object
>
>
> where ci are client interceptors and si are server interceptors.
>
> This way any aop object gets the same interceptor stack no matter if it is
> local or remote.
>
> I don't really care if either the local or remote aop object is the actual
> object or some kind of proxy: I don't think it makes any difference. I
But it does make a difference. I think a "proxy" puts restrictions on us we
don't want to have.
> don't see why the remote aop thingy can't be the actual object rather than
> a dynamic proxy, it's just that all the work gets tossed over to a
> different server.
>
> If you plan to leave out the ci's for local aop objects I want
> to know how
> you have any chance of getting even mildly similar behavior between local
> and remote versions.
>
Yo. This is exactly what I'm saying. The tx split inhibits this with AOP
because for POJOs you can't have this symetry between remote and local (if
there is no proxy object).
If the tx logic all resides in the server side interceptor, you do not have
to have this symetry because if you are local, within JBoss, the TX will
already be associated with the current thread. If you're remote, the
underlying protocol doesn't have to know about method metadata and can
extract the transaciton id generically.
>
> ===========
>
> corba
>
> My current (limited) understanding of corba tx support leads me
> to believe
> that any working corba implementation will use the corba tx policies to
> their fullest advantage and will have already established and enlisted a
> transaction branch on the corba tx manager whenever it sends a transaction
> with an invocation. We can't do anything about this, so we can't save it
> some work if it happens to be calling a method (not supported or requires
> new) that won't use the tx that was sent.
>
My knowledge of CORBA in null after CORBA 2.3, but as OLE says, CORBA has no
notion of method metadata.
> I assume we can't install any kind of real client side interceptors in
> corba, we just have to take what is sent to us. If this is wrong please
> speak up.
>
> Therefore, we have to duplicate the functionality of the client side
> interceptors somewhere on the server side in the iiop invoker. If we
> don't do this we will get the wrong semantics. I don't know exactly how
> the iiop invoker works, but I would hope that we could set it up
> so that it
> looks like:
>
> outside world >>> something corba and proxy-like > ci1 > ci2 >
ci1 and ci2 still have to know the method mappings.
> some kind of
> invoker-like thing > si1 > si2 > actual target object
>
> This is really similar to a local ejb call, except it may not start with a
> dynamic proxy ( I don't know what it would start with). Also I don't know
> it the invoker-like thing would do nothing or something.
>
>
>
> For the same reason that I think you need exactly the same client and
> server interceptors for aop objects I think you need exactly the same
> interceptors for corba and non-corba objects. With corba, these "client"
> interceptors just have to live on the server before the
> "invoker/transport"
>
Ok, let's assume that with the current code, you have JBoss's TM exposed as
OTS and the IIOP Invoker understands how to extract the TX stuff from the
CORBA request. With the way you have the interceptors written, you cannot
support RequiresNew or NotSupported because you depend on a client
interceptor to handle the semantic. With the old way of doing transactions,
you just need one set of non-protocol specific interceptors on the "server"
side since all the client interceptor does for java RMI clients is stuff the
txid in the Invocation object. Something that non-java Corba clients can
already do as well.
With your new way we would have to define 2 separate interceptor stacks for
the Server object based on protocol. IIOP would have a client tx
interceptor, Java based wouldn't have a client tx interceptor. All because:
1) YOu don't want to do the InvocationResponse thing we talked about before.
This is understandable considering (supposedly) that your design is a common
pattern/way of doing XA transactions and dealing with XA resources.
OR
2) You want to avoid propagating a transaction. Which is stupid because 2PC
is discouraged anyways and the majority of J2EE applications don't need the
semantic you're trying to achieve. You're restricting/complicating the
design just to get a little used optimization.
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
