springframework-developer

[Springframework-developer] SimpleRemoteSlsbInvokerInterceptor - create per method invocation

[Les A. H. <le...@ha...>]

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,

Les

Re: [Springframework-developer] SimpleRemoteSlsbInvokerInterceptor - create per method invocation

[Colin S. <col...@ex...>]

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,
>  
>

Re: [Springframework-developer] SimpleRemoteSlsbInvokerInterceptor - create per method invocation

[Les A. H. <le...@ha...>]

Colin,

Awesome...thanks very much for the warning.  I haven't read the J2EE & EJB specs
in over a year, so much of this has eluded my memory.  Perhaps its time for a
refresher...

One last question.  Is the majority of the performance overhead for acquiring
EJB handles incurred upon looking up the home?  If so, that would explain
caching the home for later create() method calls.

If, once acquiring the home, calling the actual create() method is a relatively
minor performance hit in comparison to doing the JNDI home lookup, most of my
concerns have been alieviated.  This behavior may be app-server implementation
specific, so I don't know that such a question would be answered in the specs.

Les

Quoting Colin Sampaleanu <col...@ex...>:

> 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,
> >
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>