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.
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.
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