Re: [hibernate-dev] [OGM] Transaction-aware

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