A generic description of reentrancy would be like this:
For any two beans A and B, if you call B's method from A, and subsequently try to call A's method from B, and the call goes through fine, then A is said to be reentrant.
From sec 10.5.11 of
EJB 2.0 Spec:
An entity Bean Provider can specify that an entity bean is non-reentrant. If an instance of a non-reentrant entity bean executes a client request in a given transaction context, and another request with the same transaction context arrives for the same entity object, the container will throw an exception to the second request. This rule allows the Bean Provider to program the entity bean as single-threaded, non-reentrant code.
The functionality of entity beans with container-managed persistence may require loopbacks in the same transaction context. An example of a loopback is when the client calls entity object A, A calls entity object B, and B calls back A in the same transaction context. The entity bean�s method invoked by the loopback shares the current execution context (which includes the transaction and security contexts) with the Bean�s method invoked by the client.
