Stateless Session bean

[sarah Marsh]

Why does Stateless Session bean not store its state even though it has ejbActivate and ejbPassivate ?
Thanks in advance,
Sarah

[paul wheaton]

My impression is that a stateless bean can be in the pool or in use. So if it is not in either of these, the bean is deleted. So, I suppose that activate and passivate are just never used. If, of course, it were a stateful bean, they would be used then.

[Priya MV]

For both Stateful and Stateless session beans we implement the same interface, i.e. SessionBean. Whether the bean is "Stateful or Stateless" is indicated only in the deployment descriptor. So the activate and passivate methods come as part of inheritance, but do not have to be implemented.

[Lasse Koskela]

Let's not forget that a stateless session bean can also hold on to non-serializable resources, which need to be handled in ejbActivate() and ejbPassivate().

[Ashish Pagare]

Let's not forget that a stateless session bean can also hold on to non-serializable resources, which need to be handled in ejbActivate() and ejbPassivate().

Are you sure with this !
Container never invokes ejbActivate() and ejbPassiavte for state-less session bean. Check the OID in the spec.

[Kathy Sierra]

Howdy
Yeah, a stateless bean will never have its ejbActivate() and ejbPassivate() method called, because passivation will never happen to a stateless bean. Passivation exists solely as a means for providing at least SOME attempt at scalability for a stateFUL bean, since stateFUL beans can't be pooled and must remain dedicated to a single client.
And Priya had the right explanation... there is only ONE interface for session beans, so that way you can choose to deploy a bean as stateless OR stateful, without necessarily reimplementing the bean (although in reality, you almost always need to KNOW whether a bean will be used statefully or statelessly, since it impacts the create() method as well as your behavior).
If a stateless bean has non-serializable state, that's OK because the bean won't be serialized. So you can hold, say, a reference to a Socket in a stateless bean, that you retrieve in setSessionContext (or ejbCreate()) and release in your ejbRemove() method (although for things like JDBC connections, you should probable retrieve and release in each business method, for better scalability).
cheers,
Kathy

[Lasse Koskela]

Thanks for the correction. I usually check with the spec, but not this time.