Discussions

EJB design: Session Bean + DB concurrency - really supported????

  1. Session Bean + DB concurrency - really supported???? (2 messages)

    My latest experiance with EJB and Concurrency has made me suspect all the hype that EJB and containers create around scalability and concurrency.
    Or may be it is my limited knowledge that is leading to this confusion.
    I have the following scenario -
    All transaction is managed by container

    QUEUE--->Message Driven Bean[REQUIRES NEW]--->stateless Session Bean[REQUIRES NEW](and DAOs)... so on

    The MDB is configured to accept multiple messages from the queue at the same time. DAOs use Datasources to get connection.
    When I have a high volume of messages in the queue, this leads to concurrent calls to SessionBean and inturn the Database. Occasionally such a situation leads to a temporary DB Deadlock and causes an exception, that would cause a transaction rollback. Where is the concurrency support boasted about? I am using webpshere5.x, DB2 and connections with READ_COMITTED Attribute.
    I could fix this problem only by re-configuring the MDBs to take messages as it comes(such a lame situation).
    Please suggest if you know of any good re-design that would allow concurrency.
    TIA
  2. Hi,
    QUEUE--->Message Driven Bean[REQUIRES NEW]--->stateless Session Bean[REQUIRES NEW](and DAOs)... so on

    EJB (at least EJB 1.3) does not support nested transactions (section 17.1.2). So when you chain "Requires New" method calls, the transaction associated with the first method is suspended at the point where it calls the second method (section 17.6.2.4). Since the first transaction is suspended, any DB locks it has are held open. Although I haven't seen it myself, I'd imagine this would cause deadlock problems if the second method tried to access records locked by the first transaction. It may also cause scalability problems (because records locks may be held for a long time).

    It strikes me as possible that your deadlock scenario shows up under high load because methods are accessing records that are locked by other methods (whose transactions are suspended).

    On a side note... What's the intended purpose of having a "Requires New" method call another "Requires New" method? Is there a specific reason why these are not just "Required"? I ask, because your scenario sounds like you're looking for robust "once and once only" message processing, but in a system where a "Requires New" MDB invokes a "Requires New" session bean, messages can be processed more than once in certain failure scenarios. A more reliable approach is to make both beans "Required" - that way, the original transaction context is propagated from the first method, so the work done by both methods is atomic. Anyway, that may not be your scenario...

    Hope that helps!

    J

    -----
    John Segrave
  3. Hi thanks for your time & reply.
    unfortunately, this is a system in production, which I am supposed to support. so I do not have clear answer why there is REQUIRES NEW instead of REQUIRED.

    But to make things interesting, there is no direct DB access from MDB. It delegates its calls to Session Bean in question.

    Thanks