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
pgpX7Bhm9c5oy.pgp
Description: PGP signature
_______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
