Sure, this is something to try out to see how much of an improvement can be made. Start with entities as these are the most likely to be created frequently. I really doubt session proxy creation can be a hotspot as its just not a frequent event in a normal workflow.
As for sharing interceptors, its a question of whether or not they have state. None currently do, but they could, for example an encryption key. We would have to have an attribute that defines whether the interceptor is stateless and if the entire stack for a container is stateless, it can be reused. Otherwise it has to be copied. xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "Sacha Labourey" <[EMAIL PROTECTED]> To: "Jboss-Dev" <[EMAIL PROTECTED]> Cc: "Scott M Stark" <[EMAIL PROTECTED]>; "Bill Burke" <[EMAIL PROTECTED]> Sent: Saturday, January 11, 2003 1:12 AM Subject: Optimisation for proxy creation? > 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
