10:14 a.m.
Hi Pawel,
On 2 April 2012 15:27, Pawel Kozlowski <pkozlowski.opensource(a)gmail.com> wrote:
Hi Sanne, All,
On Mon, Mar 26, 2012 at 3:38 PM, Sanne Grinovero <sanne(a)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-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.
Cheers,
Pawel
Cheers,
Sanne