There's no support for nested transaction. JPA and Hibernate don't support nested transactions also.
All you have is current transaction which begins with new request (well maybe a little later, when its required), and is committed after execution flow exits method with @CommitAfter. If you have nested methods with @CommitAfter you will get (in best case) two separate transactions. If you want these both method execute in one transaction then you should remove @CommitAfter from them. Then you may create new method with @CommitAfter and invoke both methods from it. You can also control transaction scope manually in some cases by injecting EntityManager (in case of JPA) and obtaining transaction from it using EntityManager.getTransaction(). You can then commit, rollback and check if the transaction is active. As a best practice in my applications I never control transactions at the DAO level. I do this in separate Managers services or at the page level depending on use case. On Tue, Jun 18, 2013 at 12:13 PM, John <j...@quivinco.com> wrote: > I have some updating DAOs that refer to other updating DAOs. Both the top > level and the lower level DAO update the same PU and use the following on > their interfaces: > > @CommitAfter > > @PersistenceContext(unitName = "DBUnit") > > Will the transactions be nested properly, i.e. will the lower levels DAO > commit actually occur on the exit of the top level DAOs method exit? I > don't want the lower level transaction to be a new and seperate one (it > should use the transaction that's already open) because obviosuly that > would not synchronize the updates with seperate transactions. > > John > > > > > -- Dmitry Gusev AnjLab Team http://anjlab.com
