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

[Emmanuel Bernard]

On Thu 2015-05-07 17:51, Gunnar Morling wrote:
> > But I could still use session.getTransaction() and get the “wrong”
> > behavior?
> >
> 
> I think it's the general question should we have an API which offers
> "everything", i.e. the sum of all functionality of all backends, meaning
> that some parts of the announced API functionality will fail at runtime
> (either silently or with an exception) on some backends. Or should we have
> a more limited API which is supported everywhere, and then allow to
> "unwrap" for certain backends (or families) and access advanced
> functionality just applying to those (as we e.g. do with the configuration
> API).
> 
> Currently OgmSession is the former, i.e. you could invoke getTransaction()
> and basically achieve the same as with the proposed alternative. But you
> could also try to rollback() and then it would fail, depending on the store.
> 
> I feel like the latter a bit better. For that we'd need a more limited
> OgmSession contract, not extending ORM's Session. This could e.g. host the
> runWorkUnit() functionality which is portable across backends.
> 
> Then there could be something like
> OgmSession.as(TransactionalSession.class).beginTransaction(). Here you
> would explicitly opt into transactional functionality. Of course you still
> could wrongly invoke this e.g. for MongoDB, but IMO it can be documented in
> a better way and help to manage people's expectations towards supported
> functionality. Or, e.g. with CDI it could even fail right at deploy of no
> TransactionalSession bean can be produced as per the current backend.

I am not sure how you reconcile that with the idea that OGM is a JPA
persistence provider implementation that integrates with things like app
servers and that these guys do use the `EntityManager` API. Will you forbid
app servers to expose rollback on the JTA APIs? And to inject a
`EntityManager` and force an `OgmEntityManager`?