CODEWITHSUNDEEP
transactionsglassfishejb
Daan de Zwart
Daan de Zwart

Reputation: 81

EJB 3.1 TransactionAttributeType.REQUIRES_NEW and setRollbackOnly

Please help me understand something about transactions in EJB 3.1. I'm using GlassFish v3 and have the following situation:

@Stateless
@LocalBean
public class BeanA {

    @Inject BeanB bean; /* which has no TransactionAttribute set */
    @Resource SessionContext context;

    public void run() {
        ...
        for (...) {
            process(someValue);
        }
    }

    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    public void process(String someValue) {

        try {

            SomeEntity entity = bean.getEntity(someValue);
            entity.setSomeProperty("anotherValue");

            ...

        } catch(CustomException e)  {
            this.context.setRollbackOnly();
        }
    }

}

BeanA.run is called from a servlet. I want to treat each iteration as a seperate transaction. I thought using TransactionAttributeType.REQUIRES_NEW would realise this, but I'm getting javax.ejb.EJBTransactionRolledbackException on subsequent iterations on beanB after having called setRollbackOnly. The strange thing is though, when I move everything but run() to a new BeanC and call beanC.process instead it does work. What am I missing? Can anybody shed some light on why this works the way it does?

Edit: Come to think of it: is it because the container doesn't intercept calls to methods within the same EJB? (which would seem reasonable)

Edit 2: Yep, found the answer here: EJB Transactions in local method-calls (I had to know the answer to find it though :))

Upvotes: 4

Views: 5606

Answers (2)

RicardoS
RicardoS

Reputation: 2118

Old question, but for the sake of completeness...

Indeed, annotations like @TransactionAttribute are not processed when they are called directly in a class. This happens because, you are calling it directly, like in a procedural function. It doesn't go through EJB lifecycle (including interceptors).

There is a way to do it though. You need to inject the self class and use that reference:

// Bean A

@Resource SessionContext context;

public void run() {
    ...
    for (...) {
       context.getBusinessObject(BeanA.class).process(someValue);
    }
}

With this way it will process the @TransactionAttribute (because it creates the proxy around it).

Although it works, in general that's not a recommended design; it might be a hint that you should split this class...

Upvotes: 1

Daan de Zwart
Daan de Zwart

Reputation: 81

Found the answer here: EJB Transactions in local method-calls

In short: the container doesn't intercept local method calls so the setRollbackOnly marked the sole transaction for rollback, explaining the exceptions.

Upvotes: 4

Related Questions