2015-05-07 8:12 GMT+02:00 Emmanuel Bernard <emman...@hibernate.org>: > > On 06 May 2015, at 15:16, Gunnar Morling <gun...@hibernate.org> wrote: > > > > 2015-05-06 14:19 GMT+02:00 Emmanuel Bernard <emman...@hibernate.org>: > >> It’s an interesting idea. >> Let me give you the reasons why I think the transaction API has merits. >> >> There is already a notion of UnitOfWork that was named Conversation in >> Seam / CDI. But its span is potentially longer than the span of the updates >> window. The closer notion of a UnitOfWork is an EntityManager or a Session. > > By introducing @UnitOfWork, you forgo all the integration between >> application frameworks and transactions. Here you offer a solution for CDI >> but we would need one for Java EE non CDI and one for Spring and one for >> Grails and one for… > > > The current integrations would continue to work. So e.g. EJB non-CDI would > still use JTA as is today. I don't find it to be a big problem there, as > it's much more under the covers (which is why it's nice to show EJBs in > demos ;). Same for the others basically. > > > OK so you would still support essentially Hibernate Transactions with how > we wired them with (compensation). >
Yes, right. Under the hood essentially nothing would change. > But also add this new concept that would do exactly the same thing for > people offended by the term transaction? Or am I misunderstanding something. > It would be similar, but not the same. Specifically, such API would not promise rollback capabilities or isolation from other, concurrent units of work when e.g. doing explicit flushes. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
