JPA and EJB - When do I need to use transaction?

Question

I'm learning persistence in Java following some tutorial.

I'm using Java EE 7 and Payara server.

I noticed that each uses a different method for persistence.

Examples:

• simple

  @Stateless
  public class BookServiceBean implements BookService {
      @PersistenceContext
      private EntityManager em;
  
      public void createOrUpdate(Book book) {
          em.persist(book);
      }
      public void remove(Book book) {
          em.remove(book);
      }
  }
  

• with flush(), this is used when validation strategy isn't set on "AUTO" in persistene.xml, right?

  @Stateless
  public class BookServiceBean implements BookService {
      @PersistenceContext
      private EntityManager em;
  
      public void createOrUpdate(Book book) {
          em.persist(book);
          em.flush();
      }
      public void remove(Book book) {
          em.remove(book);
          em.flush();
      }
  }
  

• with transaction

  @Stateless
  public class BookServiceBean implements BookService {
      @PersistenceContext
      private EntityManager em;
  
      public void createOrUpdate(Book book) {
          utx.begin();
          em.persist(book);
          utx.commit();
      }
      public void remove(Book book) {
          utx.begin();
          em.remove(book);
          utx.commit();
      }
  }
  

When and why do I have to use the last one?

Is it necessary to use em.close() at the end of each method?

What are the good practices?

Answer 1

The first one, an EJB method without all that manual flush and transaction fuzz, is the canonical approach. A single EJB method call counts by default already as a single full transaction. The EJB container will transparently begin the transaction before the method is invoked and commit the transaction when the method returns (or rollback when an application exception is thrown from the method).

The manual flush in second example is unnecessary. Generally, you want to use em.flush() only when you're modifying an entity (i.e. making it "dirty") and want afterwards (indirectly) perform a SELECT on it within the very same transaction. It's rare, but there are real world use cases for it, generally when you'd like to SELECT a parent whose the dirty entity is a child of.

The manual transaction management in third example is totally unnecessary. You should already realize that after having read the first paragraph. Manual transaction management is only necessary when you aren't using JTA, but RESOURCE_LOCAL (usually, in Java SE not Java EE).

See also:

• When is it necessary or convenient to use Spring or EJB3 or all of them together?
• JSF request scoped bean keeps recreating new Stateful session beans on every request?
• Handling service layer exception in Java EE frontend method