Can somebody explain me the foll. please. I understand "re-entrant" property as : If a method of ejb A calls a method of ejb B and if ejb B calls ejb A again, then such calls would work only re-entrant property is set to true. I read in the EJB2.0 Spec that(page:76, sec7.5.6) : "A container serializes calls to each session bean instance. Most containers will support many instances of a session bean executing concurrently; however, each instance sees only a serialized sequence of method calls. Therefore, a session bean does not have to be coded as reentrant."
What happens if a session bean is coded as re-entrant in the above scenario? Will there be a RemoteException/EJBException?
Can somebody also tell me if re-entrant property is used at all in real applications.I understand that its default value is false.
Joined: Aug 27, 2003
Section 7.11.8 in the EJB2.0 Spect is correct only if re-entrant property is set to FALSE?
"7.11.8 Non-reentrant instances ..................... One implication of this rule is that an application cannot make loopback calls to a session bean instance. "
Howdy, even at Sun they recommend that even though you CAN, you should NOT enable 'reentrance' for an entity bean (and of course, you cannot do it for session beans). It's risky and brittle, but it's allowed because there *might* be a situation where the logic calls for a bean to call another bean, and that second bean in turn calls a method on the original calling bean. Because the Container can't tell for certain that the second bean is part of the original "conceptual" call stack. If you mark an entity bean as 'reentrant', you are saying to the Container, "Trust me... I guarantee that there will NOT be any scenario in which two different threads will enter the bean, even though it might LOOK like that because of a local loopback call." If you enable 'reentrant' you are taking a very big risk, and taking on a lot of responsibility. Chances are, a decent design won't have this situation. I've never seen a design that had to use it, but it must have happened *enough* or a large enough customer must have complained that they (the J2EE team) was forced to permit it, even though they strongly discourage using it! cheers, kathy