Greet the sun all,
I have a question about the use of stateless session beans (SSB) within
servlets.
My question is this:
Within the init method of the servlet, I want to create a reference to
my SSB. Now, my choices are to create a Home reference or an actual
reference to the bean. If I use the Home reference, then I have the
performance hit of doing a create() everytime that the servlet is called
(and this servlet will be called many, many times). If I store the
actual reference to a create()ed SSB, what impact will that cause the
EJB Server and the servlet using the reference?
By this I mean, does a create() give me a reference to a 'ready' SSB or
is one assigned on receipt of the method call and I just have a pointer
to the pool?
Section 6.8 of the spec:
Because all instances of a stateless session bean are equivalent, the
container can choose to delegate a client-invoked method to any
available instance. This means, for example, that the Container may
delegate the requests from the same client within the same transaction
to different instances, and that the Container may interleave requests
from multiple transactions to the same instance.
My concern is 6.11.6:
The container must ensure that only one thread can be executing an
instance at any time. If a client request arrives for an instance while
the instance is executing another request, the container must throw the
java.rmi.RemoteException to the second request.
It does not differentiate between SSB and statefull beans. But because
SSB are stateless, can the container just delegate the request to
another ready instance or create another instance to handle the load.
One other thing, if I have a reference to a 'ready' SSB, does that
interfere with EJB server's ability to manage the SSB pool? Or does the
EJB server not care? By this I mean, my servlet instance could be
holding onto a reference that has been destroyed. Upon a method call,
would the SSB be created or a RemoteException be thrown?
Again 6.8 of the spec:
If a stateless session bean is not needed to handle the current client
work load, the container can destroy it.
Now I know one solution is to place the SSB instance into the
HTTPSession and use that. One would be needed for each client (since
the beans are single threaded and the Servlets are multithreaded).
However, the bean is not client specific and I don't want the
performance hit
of:
1. getting the initial context
2. getting home reference
3. create bean
for each client. I could perform the same set of method calls for every
doGet iteration of the servlet. What I am trying to get a handle on is
the implication of using a single SSB reference in a multi-threaded
Servlet environment.
A good example is Logging. You implement some type of Logging service
using an SSB. When the servlet is called, you want to log that the
servlet was called. You make a method call on your LogService bean
reference and say logRequest(). The EJB container intercepts the call,
grabs one of the LogService SSB beans out of the pool, invokes the
method and returns. You do not need the services of Logging for the
life of the HTTPSession, just upon the initial servlet doGet request.
I realize that some of this maybe EJB server specific.
--
Perry Hoekstra
Consultant
Talent Software Services
[EMAIL PROTECTED]
If a man is standing in the middle of the forest speaking and there is
no woman around to hear him... is he still wrong?
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
