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.opensou...@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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
