> On 07 May 2015, at 08:38, Gunnar Morling <gun...@hibernate.org> wrote: > > > > 2015-05-07 8:12 GMT+02:00 Emmanuel Bernard <emman...@hibernate.org > <mailto:emman...@hibernate.org>>: > >> On 06 May 2015, at 15:16, Gunnar Morling <gun...@hibernate.org >> <mailto:gun...@hibernate.org>> wrote: >> >> >> >> 2015-05-06 14:19 GMT+02:00 Emmanuel Bernard <emman...@hibernate.org >> <mailto: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.
But I could still use session.getTransaction() and get the “wrong” behavior? _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
