It's Taha implementing some additional transaction handling on the top of Tapestry-Hibernate/Tapestry-JPA. :)
On Tue, Jun 18, 2013 at 11:49 AM, pico.dev . <pico....@gmail.com> wrote: > What about this? > http://tawus.wordpress.com/2011/04/23/tapestry-magic-5-advising-services/ > > > 2013/6/18 Thiago H. de Paula Figueiredo <thiag...@gmail.com> > > > Tapestry-Hibernate and Tapestry-JPA were created for simple scenarios, in > > which you don't need that much control on transactions. If you really > need > > more than that, you'll be better served by EJB or Spring or something > else > > that deals with transactions in a more specifc way. > > > > > > On Tue, Jun 18, 2013 at 11:35 AM, Lenny Primak <lpri...@hope.nyc.ny.us > > >wrote: > > > > > Full JEE (i.e. Stateless EJBs) support nested transactions. > > > > > > On Jun 18, 2013, at 4:13 AM, John 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 > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > > > > > > > > > -- > > Thiago > > > -- Thiago
