You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jim Marino <jm...@myroma.net> on 2006/03/02 07:37:24 UTC

TargetInvoker and scope references

I had to make a change to the way TargetInvokers are handled in the  
invocation framework to accommodate optimizations for certain types  
of wires.  Specifically, TargetInvokers are stored in a source  
component's InstanceContext along with the source invocation  
configuration (interceptor and handler chains). When a source  
references a target that is of greater scope (e.g. request-->module)  
we want to cache the target instance in the TargetInvoker on the  
source side and pass it down the invocation chain in the request  
message. This allows us to avoid a somewhat expensive target instance  
resolution on every invoke (it just happens on the first  
invocation).   This obviously won't work for stateful scopes since  
this can lead to an incorrect target instance being invoked. For  
example, in the case where a source module component references a  
session-scoped target, the first invoke in session A will resolve the  
target instance for A while a second invoke on the source module  
component in session B will have session A's target cached on the  
module component side.

In order to fix this, I made a change where a "master" TargetInvoker  
is stored in the invocation chain associated with the component's  
InstanceContext. When a target invoker is marked "cacheable" by a  
builder, the invocation handler attached to a proxy will clone the  
target invoker and store it. This fixes the problem at the expense of  
an object clone and forcing TargetInvokers to be Cloneable.  Also, it  
makes it slightly more difficult if we want to hot-swap target  
invokers at runtime (it can still be done, but there will be more  
than one place the change must be made).

For people working on the bindings, you may notice TargetInvoker  
implements Cloneable. I changed the existing invokers to support this  
but I don't think this will impact existing code since the binding  
builders do not perform the caching optimization.

Jim