Re-entrant Entity Beans


EJB programming & troubleshooting: Re-entrant Entity Beans

  1. Re-entrant Entity Beans (3 messages)

    After reading a lot about re-entrant restrictions on Entity Beans, I really don't see why loopbacks sould be avoid,
    if we always access entity beans throw a Session Facade and don't use user managed transactions.
    I can find a way of getting into a concurrent call to the same Bean in the same transaction.
    Can someone comment on this , please ? Thanks.

    Threaded Messages (3)

  2. Re-entrant Entity Beans[ Go to top ]

    How does the server know if the attempt to call into the bean is from the currently running transaction, or a completely new client trying to get in?

    The time taken to work this out would adversely affect the performance of entity beans (which are slow enough to start with!) so it's better to simply not do it.

    Unless you mark an entity bean as re-entrant the server will simply not allow it. If you do mark it then it has to fiddle around checking the transaction context all the time.

    THat help?


  3. Re-entrant Entity Beans[ Go to top ]

    Thanks for your answer.

    I think that the container always checks for any method all to see if is from another client, to hold it if the bean is involved in any transaction.
    If the request comes from the same transaction context , than it will throw an Exception (without reentrant=true).

    My testing didn't got any additional delay using reentrant beans (Orion 1.5.2).

    And sometimes not having reentrance means , beaking all the good OO design rules, and a lot of extra code in Session Beans.

    Best regards,

    Joao Cunha
  4. Re-entrant Entity Beans[ Go to top ]

    I read a bit more about this and the main reason to avoid it is that the server has no way of telling a request from ANOTHER THREAD in the client, from the main thread allready in the client.

    In other words, if you had two threads hitting the same EJB (according to the spec, not allowed) then they have the same context as far as the bean is concerned and therefore it cannot tell the difference between the two. If the threads are from different clients that's different.

    So, if can avoid this issue, then you're fine. But beware, the onus is then on you. Since EJB was meant to avoid putting the onus on you (the client) they recommend not making beans re-entrant, since there is no way for the container to stop it happening if you do.