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