The NoSQL prototype now has transaction enlistment for Neo4j (one phase
wrapper).
Test example link [1] shows a CMT test bean method and [2] shows a BMT
test bean method.
Currently, in a JTA transaction the Neo4j Session survives ending the
JTA transaction. It might be better to close the Neo4j Session when the
JTA transaction ends, which would require the application to get a new
Session, this would ensure that applications don't forget to close the
session, with the down side that with BMT, application code would need
to call the Neo4j Driver.session(), to get a new Session instance after
each JTA transaction ends. After a session is closed, there is no
guarantee that another session can be obtained, as the next
Driver.session() may time out if the internal pool of Driver sessions,
is empty and the configured time limit
(neo4j.driver.acquireSessionTimeout) is exceeded (defaults to 30
seconds). So, there are costs to automatically closing Neo4j Sessions
at JTA transaction end time. Although, you could say that closing the
Session, after each transaction, gives other threads a change to use the
Session that isn't really closed, but instead is really returned to the
internal Driver sessions pool.
By the way, the Neo4j Session class, is what applications use to access
the database.
Thanks,
Scott
[1]
https://github.com/scottmarlow/wildfly/blob/nosql-dev9/testsuite/nosql/sr...
[2]
https://github.com/scottmarlow/wildfly/blob/nosql-dev9/testsuite/nosql/sr...
On 06/29/2016 09:50 AM, Scott Marlow wrote:
I think that we will move forward now and prototype the transaction
enlistment for ACID NoSQL databases. This is important to nail down
now, as we would like forward application compatibility. We need to
choose now, whether MySLSB.myMethod() performs the Neo4j database update
immediately when (#4) tx.close() is called or when the JTA transaction
completes. By now, I mean that we need to decide before a release of
WildFly that contains the NoSQL integration is released, so that we know
that future releases will be compatible.
I don't think that transaction enlistment should be allowed for BASE
NoSQL databases, which is why I mentioned ACID above. With BASE
databases, the application code is responsible for dealing with dirty
data. As such, I think it would be misleading to enlist BASE operations
into a JTA transaction. This means that BASE NoSQL database profiles
will not allow 1-phase/2-phase transaction attribute to be specified.
We started to write some design notes [1] for NoSQL integration. We
will update the design notes after hearing more feedback on the above.
Scott
[1]
https://developer.jboss.org/wiki/DesignNotesForNoSQLIntegrationOnWildFly