11:37 a.m.
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev