[hibernate-dev] [OGM] Transaction-aware

[Emmanuel Bernard]

I am not entirely sure how this will be shaped but I would like at least the following:

- a way to hook a fake JTA resource for backends that do not expose themselves as JTA resources
- a way to support things like entityManager.getTransaction().begin() / .commit() / .rollback(); 

for systems that have some kind of transaction demarcation.

I also want to support 

- a way to hook a fake JTA resource for backends that do not expose themselves as JTA resources
- a way to support things like entityManager.getTransaction().begin() / .commit()

but only support begin / commit (no rollback). That will help as the flush() operation will be part of the commit() operation transparently.

So to answer your question, the OGM way to start / commit a transaction would be either via JTA or via the more explicit getTransaction() APIs that Hibernate offers.
But we won't try and mimick a transactional system if there is none underneath. 

Even compensation as Sanne described it is complex and of limited effect ( what if the recovery fails :) ). so if we try and explore compensation that will be in a second step.

Emmanuel

On 26 mars 2012, at 15:38, Sanne Grinovero wrote:

> Hi Pawel,
> welcome to the brainstorming !
> 
> Are you interested in implementing JTA for a specific NoSQL store, or
> on the general problem?
> 
> Some NoSQL databases support JTA, for example both EHCache and
> Infinispan do participate in JTA transactions; for this reason the
> currently supported databases by Hibernate OGM have JTA "for free" and
> you don't find much code about it (other than binding JTA).
> 
> For other databases, they might have something similar which we could
> try to accomodate / adapt, or it might be extremely hard, or maybe
> only supportable in some specific use cases.
> 
> Taking Cassandra for example as it's one of those not having JTA and
> on which it would be very hard, it's possible that people using OGM
> will have to be aware of the limitations when picking Cassandra; this
> might be a good choice for many use cases. I would also assume that
> users will have to make such choices because of the specific isolation
> / concurrency needs they might have.. that's a good point to use OGM
> so that you can easily switch in case an initially selected database
> turns out to be a bad choice in a later phase of a project.
> 
> Ideally it would be nice if we could provide some form of
> "compensating transaction" generated automatically; that wouldn't
> provide full isolation but would likely be useful, as most NoSQL users
> are willing to pay some tradeoff for other benefits.
> 
> Cheers,
> Sanne
> 
> 
> 
> On 26 March 2012 14:11, Pawel Kozlowski <pkozlowski.opensource at gmail.com> wrote:
>> hi!
>> 
>> First of all, thank you for coming up with the idea & implementing
>> OGM. For quite some time I was thinking of using JPA annotations /
>> semantics to drive different NoSQL stores but the whole idea of
>> re-implementing the JPA machinery was really scary. Now we don't need
>> to do this anymore as we've got OGM :-)
>> 
>> For the few past days I was looking at the
>> org.hibernate.ogm.dialect.GridDialect interface (as well as at the
>> existing Map, Infinispan and Ehcache implementations) and it looks
>> like it is very easy to implement non-transactional behavior (I mean -
>> persistence of tuples and associations is really straightforward).
>> What I was struggling with thought is making a NoSQL store aware of
>> the JTA-transaction demarcation. What I would like to achieve is to
>> start a transaction in the underlying store (on transaction begin) and
>> commit/roll it back inside data store when the JTA transaction is
>> committed / rolled-back.
>> 
>> Looking at the existing implementations it wasn't easy to figure out
>> how to achieve this. Moreover I've bumped into this discussion:
>> http://www.mail-archive.com/hibernate-dev@lists.jboss.org/msg07373.html
>> where Emmanuel provided his insight: "Form this discussion it also
>> seems that we might need to have datastores and
>> dialect implement the Hibernate transaction object so that the datastore can
>> properly demarcate when isolation starts and when it ends. But that's clearly
>> not abstracted yet in Hibernate OGM."
>> 
>> In the end my question is rather simple (although answer might be
>> not...): what would be OGM-way to start / commit a transaction in the
>> underlying data store in response to JTA transaction events? Or am I
>> asking totaly wrong question and I should be taking a different
>> approach? Would be grateful for any insight.
>> 
>> Cheers,
>> Pawel Kozlowski
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev