JBossDeveloper

Sorry for my late answer :).

Those transactions are independent from each other. But step by step:

During the existence of an Extended Persistence Context there can be multiple Java Transactions (JTA).

And each Java Transaction will encapsulate write accesses to the database in a database transaction, if necessary (but I'm not sure about that). Don't know what about read accesses ;).

Usually (i.e. in a Stateless or Stateful Bean with default transaction stuff) changes to entities get written to the database at the end of a method. And those changes are encapsulated in a transaction (which is created by the EJB framework).

You might even write changes explicitely to the database with em.flush() before a method ends. Then the SQL-Statements are created immediately and submitted to the database, so you can react to exceptions if necessary (e.g. when violating db constraints).

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 :)

Plus some more questions I have:

- 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?

- 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?

- 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?

The Extended Persistence Context only says, that the entities "live" in the managed state for multiple method invocations, in opposition to the "normal" Persistence Context, in which the entities get detached after a method has finished.

Transactions are completely indepent from that. And always remember that transactions are an isolated piece of work. Just think of it as football (soccer, not american football, please *g*) matches. Losing one match doesn't mean you can't win the next ;).

There's just one thing you should bare in mind: after a rollback the involved entities might be in a dirty state.

Now, to your question: If you want to have a transaction span multiple method invocations I'd say that you should switch to user managed transactions (instead of container managed ones - there's a certain EJB annotation for that, but at the moment I don't know which one). Then you can start a transaction and finish it later, in another method. But I never did this so don't trust me without testing that yourself ;).

But, I can hear Gavin screaming, "children, don't do this at home" ;). Whenever you have a transaction opened for a longer period, you might have serious problems with scalability. Multiple open transactions may block each other. In a clean software architecture transactions are lasting only a short time.