Non-reentrant and re-entrant SBB components
An SBB Developer can specify that an SBB component is non-reentrant. If an SBB entity of a non-reentrant SBB component is executing in a given transaction context, and another method invocation with the same transaction context arrives for the same SBB entity, the SLEE will throw an exception to the second request. This rule allows the SBB Developer to program the SBB component as single-threaded non-reentrant code.
The functionality of SBB components may require loop backs in the same transaction context. An example of a loop back is when SBB entity A receives a method invocation, A calls SBB entity B, and B calls back A in the same transaction context. The method invoked by the loop back shares the current execution context (which includes the transaction) with the initial invocation of SBB entity A.
If the SBB component is specified as non-reentrant in the deployment descriptor, the SLEE must reject an attempt to re-enter the SBB entity while the SBB entity is executing a method invocation. (This can happen, for example, if the SBB entity has invoked another SBB entity and the other SBB entity tries to make a loop back call.) If the attempt is made to reenter the SBB entity, the SLEE must throw the javax.slee.SLEEException to the caller. The SLEE must allow the call if the SBB component's deployment descriptor specifies that the SBB component is re-entrant.
Re-entrant SBB components must be programmed with caution as the SBB Developer must code the SBB abstract class with the anticipation of a loop back call.
SBB components that do not need callbacks should be marked as non-reentrant in the deployment descriptor, allowing the SLEE to detect and prevent illegal concurrent calls.