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