EntityManager.flush() commits the transaction in a Java web service

Question

EDIT: Thanks everybody for your answers, but the problem was with my data source configuration, which was actually in auto-commit mode. See my answer below for details.

Both the Javadoc of the EntityManager.flush() method and searching for it in Google seem to suggest that the flush method only sends the pending statements to the database and does not commit the transaction. But a simple test web service I created (in Java 7, Oracle 11gR2, JBoss 7.1 and the Web service is packaged as a jar file) seem to indicate otherwise:

This is the table creation script:

CREATE TABLE test(
    id INTEGER NOT NULL,
    name VARCHAR2(20), 
    CONSTRAINT test_pk PRIMARY KEY ("ID")
);
CREATE SEQUENCE test_seq;

This is the corresponding entity:

@Entity @Table(name = "TEST")
public class Test implements Serializable {

    private static final long serialVersionUID = 9192814682033048425L;

    @Id @Column(name = "ID")
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "TEST_SEQ")
    @SequenceGenerator(name="TEST_SEQ",sequenceName="TEST_SEQ", allocationSize = 1)
    private Integer id;

    @Column(name = "NAME")
    private String name;

    // Getters and setters...
}

And the test web service:

@Stateless @WebService(serviceName = "TestService")
@TransactionManagement(TransactionManagementType.CONTAINER)
public class TestServiceBean implements TestService {

    @PersistenceContext
    private EntityManager entityManager;

    @Override
    public void createTest(String name) {
        Test test = new Test();
        test.setName(name);
        entityManager.persist(test);
        entityManager.flush();

        throw new RuntimeException();
    }
}

My understanding is that:

• When the createTest method is called, the application starts a new transaction
• The persist() method generates an INSERT statement to be sent to the database
• The flush() method sends the INSERT statement to the database but does not commit the transaction!
• The RuntimeException causes the transaction to rollback.

But obviously my understanding is wrong: every time I run the web service method I get one new row in the table. Moreover, stepping into this method with a debugger reveals that the row is inserted when the flush() method is called (I can "see" the row from another db session using SQL Developer).

Can someone please explain this behavior?

Answer 1

It seems that there is nothing wrong with flush() after all. The problem was that I didn't set up the data source correctly in JBoss. The lesson here is that if you want to use container managed transactions in EBJs then you need to:

• In JBoss, check the Use JTA? check box in the data source configuration.
• In Weblogic, check the Supports Global Transactions check box in the Transactions tab of the data source configuration.

Additionally, and in order to clear any confusion, the transaction management in my code is correct. Throwing a RuntimeException does rollback the Exception. Why is that? Well, from the Java EE 6 tutorial we have:

if a system exception is thrown, the container will automatically roll back the transaction.

But what is a system exception? The tutorial does not seem to touch upon the subject any further, so lets search the EJB spec. In page 382 we have:

A system exception is an exception that is a java.rmi.RemoteException (or one of its sub- classes) or a RuntimeException that is not an application exception.

OK, so maybe the RuntimeException is an application exception then? No it is not, because in page 380 we have this:

Application exceptions that are checked exceptions may be defined as such by being listed in the throws clauses of the methods of the bean’s business interface, no-interface view, home interface, component interface, and web service endpoint. An application exception that is an unchecked exception is defined as an application exception by annotating it with the ApplicationException metadata annotation, or denoting it in the deployment descriptor with the application-exception element.

So, because I didn't do any of the things listed above, the exception I throw in my code is indeed a system exception and indeed rolls back the transaction if you have set up your data source to use JTA.

Answer 2

To rollback a transaction in an EJB method you should call the setRollbackOnly() method, otherwise exiting from a method even throwing an exception causes the transaction to be commited. For a more detailed explanation you can refer to The Java EE 6 Tutorial.

Answer 3

Quoting JSR-317 of the JPA specification page 23:

Runtime exceptions thrown by property accessor methods cause the current transaction to be marked for rollback. Exceptions thrown by such methods when used by the persistence runtime to load or store persistent state cause the persistence runtime to mark the current transaction for rollback and to throw a PersistenceException that wraps the application exception.

Thus the RuntimeException you throw should be thrown from the entity bean setter NOT from the EJB.

I am sure you did not get the wrapping PersistenceException - which indicates the mark for roll back - instead you got the RuntimeException which you threw.

Try throwing RollbackException instead of RuntimeException from the EJB!!!

Or throw the RuntimeException from within the entity bean setters as the specification says.