Transactions Woes


EJB design: Transactions Woes

  1. Transactions Woes (4 messages)

    My stateless session bean has a number of methods that are marked in the deployment as Requiring a transaction.

    Now, when my client call one of those method, if a transaction does not exit, one will be created. I understood that part, but how does the EJB container knows when a transaction has ended?

    I can see how the container knows when there is a need to create a new transaction, but how does it know when to commit or when to rollback? I mean, my transaction could involve anywhere between 1 to 10000 method calls...

    Threaded Messages (4)

  2. Transactions Woes[ Go to top ]

    When a method marked as transaction "requires" get called,
    if the caller hasn't started a transaction, a single method
    run will be a transaction, otherwise it will be part of
    the existing transaction.
  3. Transactions Woes[ Go to top ]

    Yeah, I know that, but when does that transaction that was create automatically end??? As soon as the function exits?

    Say bean A has the methods a1,a2,a3,a4. All of the functions require a transaction.

    The client calls a1,a2,a3,a4 in that order. Say the client did not create a transaction, when a1 is called, a transaction is created by the container, the question is, when does that transaction gets committed or rollback? As soon as a1 exits ?
  4. Transactions Woes[ Go to top ]

    that's right. It would commit/rollback as soon as a1 exits.
  5. Transactions Woes[ Go to top ]

    The transaction ends effctively when control is passed back to the client (unless the client has created the transaction). In your case, every call to a method on the EJB will create and commit/rollback a transaction.

    If you wanted multiple method calls to be included in one transaction, you could 'wrap' the method calls in a session EJB, or create the transaction on the client.