CODEWITHSUNDEEP
javajakarta-eetransactionsejb
user2984046
user2984046

Reputation: 51

EJB TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) doesn'

I encountered an odd EJB transaction attribute problem. The @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) doesn't start a new transaction as expected.

I am using EJB 3 with Weblogic.

Here is the pseudo code:

@Stateless
public class EJB1 implements IEJB1
{
   @EJB 
   private IEJB2 ejb2;

   @Override
   public void method1()
   {
     for (i=0; i<N; i++) {
         ejb2.method2();
      }
   }
}

@Stateless
public class EJB2 implements IEJB2
{
   @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
   public void method2()
   {
     DBpersist();
   }
}

Since I specified TransactionAttributeType.REQUIRES_NEW for EJB2.method2, I expect a new transaction to be created for methood2. But during testing I found out there's no new transaction created for method2, instead method2 has the same transaction as EJB1.method1. I used Weblogic's API to log the transaction info.

I then made the following code change:

@Override
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED
public void method1()
{    
    for (i=0; i<N; i++) {
    ejb2.method2();
    }
}

This way it forced the container to create a new transaction for EJB2.method2.

But I don't understand why the container didn't create new transaction for EJB2.method2 when I had default TransactionAttributeType for EJB1.method1 (by not specifying any TransactionAttributeType) and TransactionAttributeType=REQUIRES_NEW for EJB2.method2.

I searched the existing questions related to this question. But all I found were the cases when you call a private method(with REQUIRES_NEW) from another private method within the same EJB, the container won't start a new transaction unless you call it through the EJB interface. This is not my case.

Upvotes: 5

Views: 1722

Answers (1)

aschoerk
aschoerk

Reputation: 3593

The pseudo code looks ok. This has been practiced by me in various projects so there is nothing wrong.

There might be various causes for this

  • Bug in the used weblogic version either in the interpretation of the transactionattribute inside REQUIRES or when injecting @EJB
  • Bug in usage of the transaction info api

Upvotes: 0

Related Questions