[hibernate-dev] [OGM] Transaction-aware

[Sanne Grinovero]

Hi Pawel,

On 2 April 2012 15:27, Pawel Kozlowski <pkozlowski.opensource at gmail.com> wrote:
> Hi Sanne, All,
>
> On Mon, Mar 26, 2012 at 3:38 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>
>> Are you interested in implementing JTA for a specific NoSQL store, or
>> on the general problem?
>
> Both actually. Just to give you more context I'm looking into OGM as a
> JPA interface for 2 NoSQL data stores:
>
> (1) Neo4j - from what I can see it should already support JTA
> transactions so not much problem here. BTW: is there any ongoing
> effort integrating Neo4j into OGM? If so I would be keen on helping
> out (or start looking into it if there are no such efforts).

Ok JTA should be easy with Neo4J. I'm not aware of anybody already
working on it, feel free to take the lead on this!

EHCache and Infinispan where quite similar so not too hard; people is
hacking now mostly on MongoDB integration, which is also *almost* a
key/value in essence.. so it's likely that you will need changes in
the core module, feel free to start hacking and let us know what the
roadblocks are.

We have some wikis here:
https://community.jboss.org/en/hibernate/ogm

> (2) Git (used as a versioned key-value store, based on jgit). I know
> it might sound a bit crazy but I'm using jgit as an embeded, versioned
> key value store. It works great in situations where:
>
> a) most of the content stored is text-like and strict versioning /
> history is needed
> b) a storage is mostly-read (I mean, there are far more reads as
> compared to writes)
>
> So it is really cool in situations like CMS / WIKI where content
> versioning / auditing is stricly needed. Combine it with OGM +
> hibernate search and you get a very interesting data storage.

Very surprising, but very interesting as well. you're right, there are
excellent use cases, and Git + Search is a perfect match for them.

You're not thinking of branches and similar, right?

Have you heard of Hibernate Envers ? Sounds like - in the long term -
it should expose the same APIs, as it mostly provides auditing.


> Now, for the jgit-backed storage there is no JTA support (althought
> people were thiniking about it:
> http://git.661346.n2.nabble.com/Any-plans-to-support-JTA-and-XA-in-jgit-td1495190.html)
> but from my knowledge of jgit it would be relativelly easy to
> implement (having concurent transactions would be next to impossible
> but this is not a use case I'm targetting here - sequential
> transactions would be fine for rare-write use case like CMS).
>
> So once again, given the above idea of intgrating git storage, the
> transactional behaviour would look like this:
>
> 1) on transaction's start I would rember a git's commit id and create
> an in-memory git index (easy with jgit);
> 2) any operation inside of a transaction would write objects to git's
> repo + update in-memory index;
> 3) on transaction's commit I would simply create a new commit in git
> and move rev pointer to this new commit (here is the place were it is
> very easy to detect any concurent modifications);
> 4) transaction's rollback is trivial - I would just drop the in-memory
> index (git object written to a git database would be removed during a
> standard cleanup / garbage collection of a git repository).

Sounds like an interesting plan.. but until we see the details it's
hard to see what might fail in this.

> Given the above it wonder if I should take a route of implementing an
> XAResource for jgit or maybe there is another place in OGM I could
> plug into to be notified on transaction's start/commit/rollback.

If you where to implement XAResource for jgit, that might be nice for
other projects needing it.
It also sounds like the better abstraction for OGM, since as mentioned
we currently hope to avoid needing
to manage these details.

>> 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).
>
> Yes, I see. Digging more into the EHCache and Infinispan
> implementation at the moment to make sure that I understand all the
> details.
>
> Thnx for your input so far, it would be also interesting to know if
> other people would be interested in a such versioned key-value store.
> It works perfectly for my particular use case but I wonder if others
> would be interested as well.
>
> Cheers,
> Pawel

Cheers,
Sanne