2015-05-07 10:29 GMT+02:00 Emmanuel Bernard <emman...@hibernate.org>:
> > 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>: > >> >> 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. > > > But I could still use session.getTransaction() and get the “wrong” > behavior? > I think it's the general question should we have an API which offers "everything", i.e. the sum of all functionality of all backends, meaning that some parts of the announced API functionality will fail at runtime (either silently or with an exception) on some backends. Or should we have a more limited API which is supported everywhere, and then allow to "unwrap" for certain backends (or families) and access advanced functionality just applying to those (as we e.g. do with the configuration API). Currently OgmSession is the former, i.e. you could invoke getTransaction() and basically achieve the same as with the proposed alternative. But you could also try to rollback() and then it would fail, depending on the store. I feel like the latter a bit better. For that we'd need a more limited OgmSession contract, not extending ORM's Session. This could e.g. host the runWorkUnit() functionality which is portable across backends. Then there could be something like OgmSession.as(TransactionalSession.class).beginTransaction(). Here you would explicitly opt into transactional functionality. Of course you still could wrongly invoke this e.g. for MongoDB, but IMO it can be documented in a better way and help to manage people's expectations towards supported functionality. Or, e.g. with CDI it could even fail right at deploy of no TransactionalSession bean can be produced as per the current backend. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
