|
From: Colin S. <col...@ex...> - 2004-04-20 19:46:45
|
Careful, the handles are not guaranteed to be threadsafe. On top of that, some containers do ensure they are threadsafe, but serialize all access through them. I remember back in early 2000 or so someboy here though he'd be smart and cached a stateless session bean stub in the servlet application context. This was then used to handle _all_ requests. This was with WebLogic 5.1 if I remember. The app was heavily used, and the net effect was the the serialization limited requests to about 4-5 per second. Later on somebody took over to try to optimize the app. Along with some db tweaks, they upped the number of requests per second to over 70, and I know the serialization was responsible for a good portion of the slowdown. What would probably work is a pool. But I have a feeling in practice you won't gain very much. If the methoc call every hits the db you're talking one or two orders of magnitude more work for the db access than getting the stub. Les A. Hazlewood wrote: >Hiya folks, > >I was digging around in the source code and noticed that the >SimpleRemoteSlsbInvokerInterceptor "create"s a new EJB handle per method >invocation (via the newSessionBeanInstance() method in the parent >AbstractRemoteSlsbInvoker). > >Aren't there performance implications when creating a new remote handle _per_ >method invocation? It seems to me like the performance overhead (network >calls, garbage collection, etc) could be substantial if you reference many >ejb's in a system. > >Is there a fundamental reason why the stub returned upon calling create() is not >cached for further use? > >For my own personal use, I subclassed the >SimpleRemoteStatelessSessionProxyFactorybean and created a >CachingRemoteSlsbProxyFactoryBean. This class caches the returned stub upon >the first call to newSessionBeanInstance() and then uses that stub for further >method invocations. > >Is there anything wrong with that approach? I just want to make sure what I'm >doing doesn't violate any design principles... > >Thanks, > > |