Hello,
While digging in ProxyFactory (Branch_3_0) to solve some clustering
issues/optimisations, I thought about the current proxy creation and maybe
we should do something here: I think it is a hotspot.
In getStatefulSessionEJBObject and getEntityEJBObject, each time we must
return a proxy, we:
1 - create a context object
2 - assign some id, invoker, etc. to the context
3 - create a ClientContainer that holds the context
4 - load the interceptor chain and assigne the ClientContainer as the first
element of the chain
5 - create a java proxy that holds the chain (i.e. the ClientContainer)
Elements 1, 2, 3 and 5 could be ok in term of performance. Element 4 is not
cheap. Loading the chain will iterate over the interceptor classes and
create a new instance of the class and build the chain.
Now we have two cases:
A - it is a remote call
B - it is a local call
If it is a remote call, it first mean that we could cache this chain because
it will be serialized (copied) anyway. But the next question is: what really
changes between proxies? Only the Context (that holds the identity).
Consequently, wouldn't be much more efficient (for remote call) to
pre-marshall everything except the ClientContainer and the context so that
when returning a proxy, we only have to serialize these two objects and not
the whole thing. We would have:
Java Proxy <=> ProxyHandler-ClientContainer <=> Marshalled
chain+invoker+...
|--> Context
When the proxy is unmarshalled on the remote side, the ClientContainer
starts by unmarshalling the chain (as the RMI subsystem do it currently) and
complete the chain.
If it is a local call, then the chain generation is ok as we use a
pass-value semantic and each proxy must have its own copy of the chain.
Question 1 (for local calls!): could we share *on the server* this chain
between proxies of the *same* EJB. If that's the case, then it means that we
wouldn't need to re-create this chain everytime.
Now, I've only spoken about getStatefulSessionEJBObject and
getEntityEJBObject. But now think about getEntityCollection! Its
implementation does exactly that N times! => in CMP when you return a
collection in-VM (by-reference) of, let's say 100 elements, we not only
create 100 proxies, but we also create 4x100 interceptors instances that we
plug together.
Now imagine that our client-side interceptors can be shared for all proxies
of the same EJB type (on the server). In this case, we would still have to
build 100 proxies, but no interceptors at all: we would just have all
ClientContainers target the same chain of interceptors.
Conclusion, we should look at:
- minimizing serialization work for remote calls
- minimizing object creation for local calls
Am I lost on the moon?
Cheers,
Sacha
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
