My (limited) understanding is that you create the SSB for each call from the
servlet. This will return an SSB, ready to go. You should do the
context/home bit in the Servlet init() as this is 'big hit' work. Saving the
SSB, as you noted, runs the risk of contending threads. A good App Server
will minimise the hit of the create with pooling etc, so it's not too huge -
some will (if running in the same VM as the Servlet container) optimise
further and remove the RMI layer completely (so you end up with less hit
than instantiating a Java object!).
Note that if the Servlet server and the EJB server are seperate, you can get
the CreateException if the EJB server has gone down and come back up again -
you need to trap this and re-get the context and the Home at this point.
Gluck
tim
> -----Original Message-----
> From: Perry Hoekstra [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, May 04, 2000 3:01 PM
> 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".
This e-mail, and any attachment, is confidential. If you have received it in error,
please delete it from your system, do not use or disclose the information in any way,
and notify me immediately. The contents of this message may contain personal views
which are not the views of the BBC, unless specifically stated.
===========================================================================
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".
