I have a question on Stateless Session beans: Suppose i have an boolean instance variable 'bTest' in the bean, which is initialized to false. Now suppose in my bean business method, i set bTest to true based on some condition that evaluated to true in this case (There is no 'else' case). And the Client request is serviced.
Now assume another client calls the same business method. Now in this case won't bTest still hold the value (true) from the previous invocation. And in this case won't the bean misbehave unless a different bean from the pool was picked to service the client.Thus i think the bean instance variable will be preserved from the previous invocation. Please let me know if my observation is correct. Please provide explanation if i am wrong.
If the second client gets the same bean as used by the first from the pool it will see the change the value of the boolean variable. SLSB are shared objects so the instance variables should be such that it can be shared among clients as each client does not get a separate copy of the instance.
The next client *could* get that value set as 'true', but it's not guaranteed. The container could create a new instance to handle the next client's request (and would probably do so, if the two clients called a business method on that bean's Remote interface at the same time). In other words, the behavior cannot be guaranteed.
Now, if you stored this variable as a static field in the bean, this would work, but only if your working with a single JVM. Meaning, your beans aren't deployed in a clustered environment. But, since the real only purpose of using remote object (EJBs) is to give you the ability to distribute your application, you should design your beans as though the could be in different JVMs.
The bottom line: don't configure your JVMs based on a client call. Do it from the container using the proper configuration tools.
The EJB spec requires that for a stateless session bean you must not maintain CLIENT-SPECIFIC state. You can maintain state, it just can't be state that matters to any one client.
This still allows, for example, that you could choose to cache some values as a performance tweak; as long as it would be correct for any client to use those values, that is just fine. You just couldn't assume that the cache had any particular values in it yet; you could hit a newly-created bean instance that hadn't yet had a reason to add anything to its own cache.
The important thing to keep in mind is that as the client of a stateless session bean method you know absolutely nothing about the lifecycle of the bean instance that handled your request. It could be that multiple transactions (clients) share an instance, it could be that multiple activities within one transaction all share an instance, it could be that every single method invocation irrespective of transactions get randomly distributed between instances in the pool. An instance could be alive one second, and dead the next one. You don't know, and the EJB spec says that you are required to implement the bean and client so that you don't care.
Hi all before, I think you all are talking about the "state" held in _member_ variables?
1) If you pass in state via a _parameter_ of the called method and do not assign it to member variables, then there will be no state sharing and thereby no lost updates, right?
The parameter object passed in by one client never is seen by any other client (if the two clients did not allready share the parameter before calling).
2) Even in case you provide _member_ variables I thought this is guaranted to be stable until the single call returns. No reason to think about further or later values in those member variables. As long as your call does not return this session bean will never be shared to other callers.
"Shared" just means it is not garbage-collected after each return and not expensively created on each call. It does not mean that a stateless session bean may be shared at the same point of time. If the latter would be true, we would just need one single SLSB and not a pool of it.
So you just need to - initialize all member variables yourself and - do not rely on any former values. Do you agree?