Just wanted to add that ONLY entity beans have the *option* of allowing reentrant calls. Session beans and MDBs don't have that as an option.
Reid's explanation is the one to pay attention to:
bean 1 calls bean 2... and somewhere bean 2 calls bean 1
So... what do you end up with? If this were a *real* call stack you'd have a call to bean 1 on the stack, then bean 1's call to bean 2, then bean 2's call back to a bean 1 method would be on top. This doesn't sound like it should be a tx problem, because the transaction is associated with the thread... and it *looks* like we have just a single thread stack of execution.
BUT... we're talking about beans. And bean 1 doesn't *really* call bean 2 and bean 2 doesn't *really* call bean 1 again. Everything goes through the Container via the
EJB object. And the Container might be managing all of this using multiple threads, even though the Container is protecting your beans and keeping them thread-safe.
So to the Container, it cannot necessarily tell the difference between a reentrant call (bean 2 calling back to bean 1 as part of the *virtual-but-not-REAL call stack*) and simply a new call to bean 1 while bean 1 is already in a method call. In other words, the Container doesn't KNOW that bean 2's call back into bean 1 is part of the same original method call (which means that it isn't a problem), and for all the Container knows... this second call into bean 1 is really coming from some *other* client.
This means that while reentrant calls are not technically a problem, if you tell the Container to ALLOW them, then you are ALSO telling the Container to just allow calls that might, in fact, be compromising your thread safety. You're telling the Container "trust me... I know what I'm doing and if these multiple calls come in to the same bean instance you can just relax. It's just a reentrant call and not a new client..."
That's why in the spec even, you're discouraged from ever allowing reentrant entity beans. But they permit it because you might have a design that absolutely requires it.
Anyway, it applies only to entity beans. Session beans can't allow reentrant calls even if they beg, plead, cry, and threaten.
cheers,
Kathy