Perry,
Since serlvets are re-entrant and Session Beans are not, you must either
create() at each web hit, our pool the session beans used by your servlet
layer.
This has been covered in earlier threads in the archives.
Regards,
-Chris.
PS: The GemStone/J Developer's Guide has an open source example of this.
> -----Original Message-----
> From: Perry Hoekstra [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, May 04, 2000 10:01 AM
> To: [EMAIL PROTECTED]
> Subject: Servlets using Stateless Session Beans
>
> 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".
===========================================================================
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".
