Why the Session beans should not be re-entrant and the same way entity bean should be re-entrant? Why the container manages the thread synchronization then what is the point in having a separate property called re-entrant ?
Created May 7, 2012
Entity EJB can be shared between clients but Session EJB cannot.
Logically (but not necessarily implementation-wise in a container) this means that in a container there will be many session beans connected to clients and, hidden behind those Session Beans there will be much fewer Entity Beans.
This implies that the Entity Beans could possibly benefit from being re-entrant, meaning that requests to them will not be serialized.
Even though session beans are synchronous, the fact that entity beans can be shared between clients means that an entity bean can receive a request that originated from a client B, while being buisy handling a request from a client A.
Whether or not an application server will or can take advantage of the "re-entrant" field in the deployment descriptor is vendor specific.
Without going into too much detail, an application server that relies on the database for transaction management, f.ex., will likely not read the "re-entrant" field at all, because it will create entity beans on demand, not share them and thus not serialize access to them - making re-entrancy become a no-issue.
This means that the container has at least 3 ways of dealing with this:
Note that in all cases, the entity bean can be passivated.