Re: [wildfly-dev] (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration...

Hi Gunnar/Emmanuel, The Ne04j profile can either be "transaction=1pc" (JTA transaction enlisted) or "transaction=none" (will not be enlisted into JTA transaction). I think this covers what Emmanuel suggested (I didn't get Emmanuel's email yet for some unknown reason). It sounds like we aren't yet connecting on what the WF Neo4j profile is doing, so I'll respond below and we can continue from there. :) On 07/13/2016 01:16 PM, Gunnar Morling wrote: > Hi Scott, > > I had a short look at the tests you pointed to; in the one using BMT, > why is it that the UserTransaction *and* the Neo4j TX API are used? I'd > have expected it to be only one *or* the other? With both container managed transactions and bean managed transactions (BMT), a JTA transaction is in control of the transaction. With BMT, UserTransaction is used by the application code to start/end the transaction. In either case (BMT or CMT), the Neo4j TX API is controlled by the JTA transaction. If there isn't an active JTA transaction, the Ne04j TX API is in control of the Neo4j transaction. With one caveat, that the Ne04j transaction should be ended by the application code, before entering into a JTA transaction (since it won't be joined into the JTA transaction). Users can also disable the JTA transaction enlistment by using a NoSQL profile with "transaction=none", instead of "transaction=1pc". > > In the one using CMT, there are also calls to the Neo4j TX API which > apparently are ignored. With CMT + BMT, the JTA transaction is in control, when the JTA transaction ends, the Neo4j transaction ends as well and not before then. If the application calls the Neo4j TX API, our TXProxy ignores calls to TX.success/failure/close, other calls are passed through to the underlying Neo4j Transaction object (e.g. run(String statement)), since that is where the work actually occurs. When the JTA transaction commits, the underlying Neo4j tx.success() + tx.close() are called. If the JTA transaction rolls back, the underlying Neo4j tx.failure() + tx.close() are called. > What's the rationale behind that? To enlist the Neo4j transaction into the JTA transaction via a one phase wrapper. > Wouldn't it > make more sense to raise an exception, similar to when > EntityManager#getTransaction() is invoked for a JTA entity manager? If the NoSQL profile is JTA enabled, it should be enlisted into the JTA transaction, allowing the application to control all of the database operations that occur within the JTA transaction. We also have the equivalent of JPA RESOURCE_LOCAL, via NoSQL profiles that are not JTA enabled ("transaction=none" in the profile definition). > > In the CMT case, did you consider to inject the Neo4j Session instead of > Driver into the bean, again akin to injection of JTA entity managers? It is possible that we could also look at TransactionScoped injection of sessions, but not sure yet. We started with (RequestScoped) Session injection but commented that out [1] when we added JTA enlistment. TransactionScoped injection of Sessions could be yet another way to write CMT/BMT code. > > All in all, I'm wondering whether things couldn't be handled analogous > to the usage of entity managers: > > * For a JTA-enabled NoSQL persistence unit, obtain the Session via > injection (its lifecycle is controlled by the container and bound to the > managed transaction), any manual interaction with the Neo4j TX API is > forbidden, instead the container manages transactions or the user is > (via UserTransaction) > * For a non-JTA-enabled NoSQL persistence unit, obtain the Driver via > injection, and the user is in charge of Session lifecycle and > transaction control Well, you haven't yet seen the above responses yet, I think the TransactionScoped Session injection idea is good but also introduces a different way to write CMT/BMT code for Ne04j. I disagree on making the current (WF NoSQL/Ne04j TX enlistment) approach illegal, as I don't yet see a problem with the current approach. Are there difficulties with Hibernate OGM that you anticipate with either approach of JTA TX enlistment for Neo4j? > > I hope that'd make sense for actually transactional stores such as > Neo4j, for non-TX stores such as MongoDB thinks look different. Agreed, for MongoDB, we treat that as "transaction=none", meaning no JTA transaction enlistment for MongoDB. > > --Gunnar > Scott [1] https://github.com/scottmarlow/wildfly/blob/nosql-dev9/nosql/neo4j/src/ma...