Re-Entrant in EJB


EJB design: Re-Entrant in EJB

  1. Re-Entrant in EJB (4 messages)

    Hi All,
           What is meant by re-entrant in the context of EJB?
    In the deployment descriptor there is an option for re-entrant in weblogic5.1 server.

    Threaded Messages (4)

  2. Re-Entrant in EJB[ Go to top ]

    Re-entrancy is forbidden by the EJB spec. An example might be 3 session beans A and B and C. A calls B which passes a reference of itself to C. C tries to make a call on B. This is re-entrant.

    Dave Wolf
    Internet Applications Division
  3. Re-Entrant in EJB[ Go to top ]

    A little correction, here.

    It is not forbidden, but it is "not recommended".

    The specification throws some nonsense about the difficulty of an app-server to make the distinction between a concurrent call and a re-entrant call.

    They got that very wrong, or they might have said better, a lazy app server, like if we were to do it ourselves, may find it very tough to handle this situation.

    As a matter of fact an app server has no excuse for not being able to deal with reentrant calls.

  4. Re-Entrant in EJB[ Go to top ]


    Actually its imporant to give the distinction between a session bean and an entity bean here. Yes the spec only "suggests" avoiding re-entrancy of entity beans. It is however much clearer on the prohibition with session beans as shown in 6.11.6 of the EJB 1.1 spec.

    That said, in Sybase EAServer we do enforce this by default but you can feel free to disable our check here. We have always supported re-entrancy and can support it for EJB as well. Simply go to the instances tab of the components property sheet and check of "renentrant". The app server is quite capable of handling this.

    Dave Wolf
    Internet Applications Division
  5. Re-Entrant in EJB[ Go to top ]

    Re-Entrant is more problematic for EJB than container..
    the container can tell this easily by comparing caller and
    callee's transaction id, the really trouble is it may cause
    deadlock in the EJBs.. e.g. the method being marked as
    transaction requires new and the database isolation level
    is repeatable read..
    Dave, why the spec treat EB and SB differently? My guess
    whould be matching with the EJB model: session beans always
    single threaded serving one client, while entity bean
    is more reusable so the designer should already have
    considered the re-entry problem.

    Correct me if I am wrong.