[asookazian]

From JPwH:

If the method returns, and if the transaction was started for this method, it's committed.  Each EntityManager has a persistence context that spans the scope of the transaction and is flushed automatically when the transaction commits.

A system exception thrown by an EJB method enforces an automatic rollback of the system transaction.

The example in this scenario is using a tx-scoped PC via @PersistenceContext.

So perhaps you're correct but I do remember stepping thru a method in the debugger and after execution of the entityManager.flush() in a manual flush scenario, I ran a select sql statement and it already had reflected the update/insert operation for the target table.

So what would be interesting to try is to do a entityManager.flush(), run a select, then throw a RuntimeException to see if the changes are undone...

[yasudevil]

Well I don't know if I really got to your point.

But after the entityManager.flush() and my exception being throw I access the system once more and the changes were indeed comitted.

When I do a search, for example, the name of my entity has changed.

[asookazian]

show your components.xml, persistence.xml and the class which is executing flush().

[yasudevil]

Well I discovered the source of my problem.

Firstly I'm deploying the application on Glassfish so this attribute may not exist in JBoss AS.

In my connection pool definition I had the following line.

non-transactional-connections="false"

This line was preventing my connection to start a transaction.

[yasudevil]

Sorry, I have made a mistake in the previous post. I inverted the situation of my property.

When the changes wasn't rolling back the property of my connection was.

non-transactional-connections="true"

when I changed to

non-transactional-connections="false"

Then even flushing the entityManager and after that throwing the runtime exception caused a rollback.