EJB Reentrance


EJB design: EJB Reentrance

  1. EJB Reentrance (3 messages)

    The general impression is that making your EJBs reentrant is A Bad Idea(tm). I can see that this would have impact on the transactional integreity, but I'm having trouble visualising exactly why it's a problem.

    Maybe it's just been a long day, but could someone draw me a mental picture?

    Threaded Messages (3)

  2. EJB Reentrance[ Go to top ]

    Consider a web application where a user can update order data through an HTML-based interface. The Order entity may have a method for adding items to it, which is called by a Servlet. Consider this pseudo-code:

    void addItem(Item item) {
    // add item to order
    // recalculate order price
    price = calculatePrice();

    Now consider what happens if the user accesses the page once, and then quickly accesses it again (in the same transaction).
    The container generally can't tell that these are concurrent calls rather than loopback re-entrancies, so it will allow both requests to go ahead to the same instance.
    One thread may update the order, run calculatePrice(), and then switch off to the other thread right before assigning the new price. Now the other thread finishes, assigns a price, and then our old thread makes it's own assignment with the value it calculated before. So you end up loosing the price of the second item.
    This is a simplistic view, but of-course many other things can go wrong when two threads modify the same data structure.

  3. EJB Reentrance[ Go to top ]

    Ah, fair enough. The documentation on the re-entrance parameter seems to emphasise the "loopback" issue, whereas the problem seems simply to be one of thread synchronisation. Nothing specific to EJB applications.

  4. EJB Reentrance[ Go to top ]

    Yes, it's not specific to EJB.
    The only thing you need to know about this problem regarding EJB is that the server won't block concurrent calls in the same transaction when you allow re-entrancy. This has a very practical reason - the server usually has no way of telling a loopback apart from a concurrent call. It's not an intentional design concept.