create transaction enlistment prototype for Ne04j

[scottmarlow]

Similar to the http://lists.jboss.org/pipermail/wildfly-dev/2016-June/005209.html suggestion, except we can try enlisting into the JTA transaction, so we can commit or rollback the Neo4j transaction when the JTA transaction completes, instead of the suggested commit/rollback during a Synchronization.afterCompletion(), which is too late to save database changes (IMO).

[scottmarlow]

Gytis, I'm already working on this.

[scottmarlow]

I think that we should collaborate on the different possible approaches mentioned on https://developer.jboss.org/wiki/DesignNotesForNoSQLIntegrationOnWildFly and review what I just pushed to nosql-dev9.

[scottmarlow]

nice, I was able to also assign this issue to me

[gytis]

Your implementation of one phase looks nice! But which other approach do you have in mind? Two phase is not available at the moment as far as I understand.

[scottmarlow]

Once a NoSQL vendor implements a full two phase XAResource (or equivalent), we could try adding support for that (assuming the NoSQL vendor has an api that makes their XAResource implementation available to us). If NoSQL vendors do not ever implement XAResource, that is also okay, we just won't bother implementing two phase support. The current prototype is using Java proxies, which should probably change to generated Java bytecode. We should integrate with another NoSQL vendor that also provides one phase, perhaps http://orientdb.com/docs/last/Transactions.html, so that we can better create an abstraction for one phase support, that could work for both. Initially, we would probably clone what we have for Neo4j, to work for OrientDB.

[gytis]

That sounds like a correct path. Do you plan to do that yourself or pass it on to me?

[scottmarlow]

I think that either you or me could work on it. I plan to update the wildfly dev ml thread today after I finish adding some comments to the tx enlistment tests, and based on the feedback, will update the Neo4j prototype and design doc. Do you want to start adding an OrientDB subsystem?

First question to answer is how they manage the remote OrientDB connections, that we could inject into user applications. Second question, is whether the injected OrientDB connection are shareable between threads or not. For example, with OrientDB, the Driver is shareable (thread safe) but the Session/Transaction classes are not shareable. We currently can inject the thread safe Driver but not Session. With Mongo, the MongoClient is thread safe and shareable, the MongoDatabase is also supposed to be thread safe and shareable, so we allow both to be injected.

If you take on the challenge of OrientDB, which I think is an excellent idea, you should create a tracking issue, so we can share concerns/progress/success via :-)

I think that after we add another NoSQL vendor, like OrientDB, we should take a look at abstracting common logic, so that we can share code between the different subsystems.

Thanks, Scott

[gytis]

Sounds great! I'll go ahead with OrientDB then.

[scottmarlow]

Note that we recently discussed a change to not allow the Neo4j Transaction api to be called within an JTA transaction that Neo4j is enlisted into. Instead the application can rely on JTA to control the transaction. Calling Session.beginTransaction() will throw a RuntimeException.