CODEWITHSUNDEEP
jpajakarta-eeejbjava-ee-6
miha
miha

Reputation: 3377

How to persist JPA entities even when EJB method throws an exception?

I have an EJB, whose method (among other things) persists JPA entity. If the method throws an error, the transaction is rolled back and the entity is not persisted.

However, I do want that entity to be persisted regardless of any exceptions, that might occur in the EJB method.

I'm using WebSphere 7.0, EJB3.0, JPA 1.0 (OpenJPA that is in WAS), DB2, if it matters.

I tried setting @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) on top of EJB; with that, entity is not persisted even if there is no exception. I also tried commiting transaction myself (em.getTransaction().commit()), but getTransaction() throws exception (because transactions are managed by container).

Upvotes: 0

Views: 2759

Answers (2)

Edwin Dalorzo
Edwin Dalorzo

Reputation: 78579

I am not an expert on EJBs, but I have been dealing with JPA and transactions for a few days now.

I recently answered another question about how entities resided in a context, and how this works in Java EE applications, the context is linked with your JTA transaction.

You can see details of this answer by clicking here. I think it is useful to understand how to context works in order to comprehend the nature of problems like the one you describe.

If you do not provide transaction support, then there is nothing to persist from the container standpoint, and therefore, your changes to the context are transient.

Also you have to consider that once an exception occurs, your context becomes invalid, and the entities in it get detached. (There are a few exceptions to this, like NoResultException).

Thus, from that point on, if you want to commit something, you need a new JTA transaction, with a new fresh JPA context in order to be able to commit changes to the database.

As I said, I am not an expert in EJBs, but if your method fails due to exceptions and you still would like to retry the transaction again by re-invoking the method, then you could force a new transaction to be created every time the method is invoked and by this, you would create a new fresh JPA context.

On the other hand, if you want your modifications to the entities to be persisted, regardless of exceptions in the method, then you might like to consider moving the code that is updating the entities to a new EJB method defined to start a new transaction (TransactionAttributeType.REQUIRES_NEW) every time you invoke it.

By the time this second inner method finishes, your work over the transactions will be automatically flushed to the database, regardless of the outer method of you EJB failing.

Basically, you would be providing a new context for your entities, and linking such context to a new transaction, scoped to commit when the inner method completes.

The natural behavior in EJB containers, as far as I understand, is that ever method joins the already existing transaction, and this is what you might like to prevent, from my point of view.

Another alternative: if you want to control your context using a different transaction support then you might like to consider providing a resource-local based persistence unit and you can manually instantiate your entity manager and control transaction scope as you wish. But honestly, this does not sound like a good idea to me, at least no in the context of the problem that you described.

Upvotes: 1

Brett Kail
Brett Kail

Reputation: 33936

Use bean-managed transactions.

@Stateless
@TransactionManagement(TransactionManagementType.BEAN)
public class MyEJB {
  @PersistenceContext(unitName="...")
  private EntityManager _em;
  @Resource
  private UserTransaction _utx;

  public void myEJBMethod() {
    _utx.begin();
    // Use _em
    _utx.commit();
    // Do other work that might throw an exception.
  }
}

Alternatively, use TransactionAttributeType.REQUIRES_NEW as suggested by edalorzo.

Upvotes: 2

Related Questions