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

[Gunnar Morling]

2015-05-07 8:12 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

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