[hibernate-dev] [OGM] Transaction-aware

[Strong Liu]

yeah, using Git as back end storage is very interesting, is there already code i can follow?
-------------------------
Best Regards,

Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio

On Apr 2, 2012, at 11:14 PM, Sanne Grinovero wrote:

>> 
>> (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.
>