Jon Dart wrote:
> I'm working on an EJB application that needs to instantiate a fairly large
> Java library (which does a bunch of complex and somewhat expensive
> operations on startup).
>
> I really only want to start up one copy of the library, or at most a few
> copies .. certainly not one per client. So I have tried making the client
> access a stateless session bean, and have that bean lookup and
> load a stateful session bean, that in turn loads the library.
>
> My reading of the EJB spec suggests that a stateless session bean
> can be reused to service multiple clients .. i.e., while only one client
> at a time is accessing it, it doesn't necessarily go through a remove/
> create cycle when the next client comes in. When the client does
> a remove(), the server can choose to keep the bean instance around
> for the next client, and not call its ejbRemove() method.
>
> If this were the actual behavior, then it seems that I would get the
> desired result. However, the J2EE reference server does not seem
> to recycle the stateless session bean in this way, nor does a
> commercial server I have tried (name withheld).
>
> Can I rely on this behavior? If not, would funnelling my library
> access through a custom resource manager (with some kind
> of pooled access to the external Java library) solve this problem?
And Mark Hapner replied:
> As long as your library session bean does not retain client
> conversational state across method calls it is 'stateless' from the EJB
> perspective. Stateless in the EJB sense means no client conversational
> state. A stateless session bean may have bean state as long as any bean
> instance can service any method call.
>
> As you note, EJB does not require a server to recycle/pool stateless
> sessions beans. My impression is that most servers will soon support
> this optimization if they don't already. I wouldn't go to the trouble of
> trying to work around those that do not.
Although Mark is (of course!) technically correct I am less convinced than he
that all servers will support this optimisation and I certainly don't believe it
could be mandated in the spec that the data must available for the next client
of the bean. (How long would the data have to be kept in order to conform to the
spec? What about designs which pool skeleton beans across multiple bean types?).
In any case, that is not the issue. Quite simply, (ab)using stateless session
beans for this purpose is wrong. Server algorithms for reuse of stateless
session beans will be designed to help optimise SERVER resources, not Jon's Java
Library (JJL) resources. So depending on the workload there may be many more
stateless session beans than JJL needs or wants resulting in excessive memory
usage. Or they may be freed up very frequently resulting in excessive JJL
initialisations.
Implementing JJL as a resource manager is the right way to go, and the J2EE
connection framework defines (will define) how such a resource manager should be
accessed. Using it you will be able to optimise the number of copies of your
library as you see fit.
The requirements are out there for many different sorts of JJL, so you are not
alone. But until the connector framework is available could you use non final
static to hang copies of your initialised library from?
Ian McCallion
CICS Business Unit
IBM Hursley
[EMAIL PROTECTED]
Tel: ++44-1962-818065
Fax: ++44-1962-818069
===========================================================================
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".
