The session objects are pooled (and lazily constructed).
This means your ejbCreate() won't be invoked until the first request.
It is not when they do home.create(), this just creates a proxy to the bean without
doing anything with bean instances.
Once your object is in the pool, it won't invoke ejbCreate() again.
If you want to configure expensive resources you should consider
JCA. Or if there is no need for transactions and security and MBean.
having a field in stateless only makes sense if all the sessions need that field. If the field is session specific then you need stateful sessions.
Hi Adrian and Marc,
The field I want to put in the stateless session bean is not session specific.
(the bean has only one method).
It holds reference to an array of objects that I want to be instatiated before the client invokes the EJB method.
So I want to instantiate these objects when the container call the ejbCreate() method.
But I want to know what happens when the same bean instance serves a different client??
Will the objects that have been instantiated when the container called ejbCreate() method be available to that new client???
And in general, is there any impact on performance to declare a private field in a Stateless session bean???
Thank you very much
Yes the objects will be available to all clients (they're pooled). So if you use instance fields they must be immutable throughout the life cycle of the bean (or you need to figure out how to notify the bean instances of the state change)
Thank you very much.
I wandered whether there is a harm to call a singleton class from the ejbCreate method in order to retrieve the array of objects and populate
the bean's instance field with it?
I know that EJB must avoid using static fields and the singleton class has static field.
Do you think it's a good choice to do like that??
Could this raise performence issues??
I precise that the bean's method delegates every client call to the objects method contained in bean's intance field.
Thank you very much.
If the singleton returns immutable values it should be ok. Mutable values don't work in a cluster setup.
Your advice is very helpfull.