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

[Hardy Ferentschik]

Hi,

On Wed, May 06, 2015 at 11:01:29AM +0200, Gunnar Morling wrote:
> When talking to people about OGM, there is always that awkward moment when
> you need to explain that TX demarcation is required also for
> non-transactional data stores.
> 
> While it makes sense for our purposes (we use the "TX cycle" to optimise
> the work sent to the backend etc.), I can understand people who find that
> odd API-wise. So I was thinking about how this could be improved.

Personally I count myself to the category of people who raise an eyebrow about
using transactions for non transactional data stores. 

> When it comes to CDI, a more "neutral" annotation (and a portable extension
> examining it) than @Transactional could be helpful:
> 
>     @UnitOfWork
>     public void saveOrderAndCustomer(Order order, Customer customer) {
>         session.persist( order );
>         session.persist( customer );
>     }
> 
> By means of the @UnitOfWork annotation it would be expressed that the
> entire method should run as one "transaction". This also could be used to
> specify an error handler for our new API to be applied for this unit of
> work:
> 
>     @UnitOfWork(errorHandler=FailedOpsLoggingHandler.class)
>     public void saveOrderAndCustomer(Order order, Customer customer) { ... }

Interesting.

> In non-managed environments, Java-8-style Lambda expressions could be
> leveraged nicely to achieve the same:
> 
>     session.runUnitOfWork( () -> {
>         session.persist( order );
>         session.persist( customer );
>     };
> 
> This should feel much nicer to e.g. users of the MongoDB backend than
> invoking session.getTransaction().begin()/commit(). It also plays greatly
> together with the error handling stuff:
> 
>     session.buildUnitOfWork( () -> {
>         session.persist( order );
>         session.persist( customer );
>     } )
>     .onFailedGridDialectOperation( context -> {
>         // e.g. log failed op
>         return ErrorHandlingStrategy.ABORT;
>     } )
>     .onRollback( context -> {
>         // e.g. log applied ops
>     } )
>     .run();
> 
> Of course something equivalent could be done for Java 7, but it'd probably
> look not as concise.

I like how the lambdas play out there. Personally I think it would be more important
to start with a Java 7 based approach. Only offering this type of functionality for Java 8
might limit the potential user base and it also adds some complexity to OGM as well,
since you probably still want to offer Java 7 compatible artifacts. That said, I think the
lambda approach has definitely a future.

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150506/86cf0890/attachment.bin