Hi Piyush, The EJB life-cycle is thoroughly explained in both the EJB specification and any good book on EJB (like "Mastering Enterprise JavaBeans" by Ed Roman, or "Enterprise JavaBeans" by Richard Monson-Haefel, or "Enterprise JavaBeans" by Tom Valesky). What resources (if any) have you read regarding the bean life cycle? Did you have trouble understanding them? Is there a specific aspect of the life cycle that you have a specific question about? I don't think it would be very helpful if I just repeated the explanation that you can find in all of the resources I mentioned above. Good Luck, Avi.
Avi has a good point, but I'll give you a little information, which may be what you are looking for. Stateless session bean and message bean calls are not reentrant, which means that if two clients make calls simultaneously, they will be serviced by two distinct instances of the bean. Once a bean method returns however, the next call, even it is from a different client, may be handled by the same instance of the bean.
Keep in mind that most of the lifecycle of EJB (in the spec) is more of a "conceptual" model rather than an actual "here is how it is implemented and here are the number of objects, etc.". In other words, the spec tells you how to THINK about the way it works, but how the vendor actually implements it is largely up to the vendor. The spec tells us (the developers) what the container is guaranteed to do -- for behavior -- but we can't always know exactly how many objects they've instantiated to do that work. For example (but I'm dusting off my very old EJB experience here, so someone more current might have more insight): * We "think" of entity beans as having at least one EJBObject per each pk that's being used while the container is running. We "think" of the PK as being stored in the EJBObject, since we know the actual entity bean instances themselves are pooled, but how do you tell the container you (the client) are done with the entity bean? There's no explicit mechanism, so while you DO tell the container when you're done with a stateful session bean (remove()), this doesn't apply for entity beans. So people sometimes ask, "what happens to all those entity EJB objects after there aren't any more clients holding an active reference to that particular Component Interface (for that particular entity)?" Answer is, we don't know for sure from the specificaion. So for all we know, with a remote interface, the vendor is storing the PK in the Stub object, rather than the remote (EJBObject). So that there is NOT one EJBObject per entity bean PK that's been requested, even though we can "think" of the lifecycle as though that were true. Again, forgive me if all of this has been said to death here. I'm just coming back in after a very very long absence. Kathy (aka cowgirl)
Co-Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0596007124/ref=jranch-20" target="_blank" rel="nofollow">"Head First Design Patterns"</a><br /> <br />Just a Jini girl living in a J2EE world.
I helped write a Developer's guide to EJB listed in my signature. It is free and it explains the lifecycle well. Different types of beans have different lifecycles. For example, an entity bean has a long lifecycle as it represents persistent state, i.e., like a row in a database. A stateful session bean is created when the end user session begins, and remains untill the session ends. It holds conversational state for the client session. A stateless session bean can live or die outside of a particular session because it does not have affinity to a single client like a stateful Session bean. Ditto for MDB. For more details, see the free developer's guide to EJB listed in my signature.