Stateless session bean instances are pooled by the container. When client invokes a method on a stateless session bean, container moves the bean instance back to the pool once the method completes. There is no way you can make a single stateless session bean instance to receive all the client calls. The next time client invokes another method on the same stateless session bean, container chooses any bean instance from the pool and the client has no control over it.
Then EJB is the wrong technology to use. Why must every client connect to just one instance of a class? [ June 08, 2006: Message edited by: Paul Sturrock ]
zb cong
Ranch Hand
Joined: Jan 14, 2002
Posts: 403
posted
0
it just my thinking, there is not real work request, considering:
if i want to instantiate many java objects when the session bean is created,then every session bean will keep the same copies of these objects,it is resource consuming, so i think if i can make this session bean singleton, it maybe sovle this problem. what do you think?
zb cong
Ranch Hand
Joined: Jan 14, 2002
Posts: 403
posted
0
i think out a solution, don't know if it works as what i want.
write a singleton java class, in this singleton class, i find the session bean by jndi then create the instance, and save the reference within the singleton, every client code can get referece to the session bean, can it promise the session bean singleton?
Turn that around. Allow any number of session bean instances but do the work in a POJO that gets a singleton in the normal fashion.
If your goal is to cache something less than one instance of common data per session bean this will do the job. If your goal is to cache exactly one (two would be failure) I'd worry about the container using different classloaders causing you to make multiples.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
0
