"bfo81" wrote : | But I must confess, I am not 100% sure at which point in time a transaction starts and ends. My imagination is like this: | - before methode starts: em.getTransaction().start(). | - after method ends: em.getTransaction().commit() (or rollback() if setRollbackOnly() was called or a RuntimeException occured). | - and whenever there are Java transactions running, a database transaction is started before the first db access (e.g. set autocommit=0 in MySQL or begin tran in MS SQL). And after writing was finished, a database commit (or rollback) is called. | | GAVIN? Could you take as on a ride into the deep misterys of the Java Transaction API and its interactions with the EntityManager here? Only a short comment wether my findings are correct :) It all depends upon the TransactionAttribute used. The default behavior is TransactionAttribute.REQUIRED. But note that if you use TransactionalSeamPhaseListener, there will already be a txn active before you hit the EJB tier. "bfo81" wrote : - If a rollback was set (setRollbackOnly() or RuntimeException) there won't be any SQL statements sent to the database at the end of a method. If you called em.flush() before, then statements were already created and only then you need a database rollback, right? huh? "bfo81" wrote : - Ist there a SQL commit called at the end of em.flush()? If yes, and if there are e.g. constraints violated, the database rolls back the changed stuff automatically and throws an exception, right? definitely not. flush() flushes, it does not commit "bfo81" wrote : - How does the EntityManager know which entities changed? Does he hold a copy of every managed entity in memory and compare it to the actual entities, field by field?!? Or are there some interceptors doing some observer stuff on the entity? EM keeps a snapshot, at least in our implementation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993160#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...