[hibernate-dev] [OGM] Demarcating units of work

[Emmanuel Bernard]

> On 07 May 2015, at 08:38, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> 
> 
> 2015-05-07 8:12 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org <mailto:emmanuel at hibernate.org>>:
> 
>> On 06 May 2015, at 15:16, Gunnar Morling <gunnar at hibernate.org <mailto:gunnar at hibernate.org>> wrote:
>> 
>> 
>> 
>> 2015-05-06 14:19 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org <mailto:emmanuel at 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?