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

[Scott Marlow]

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/main/java/org/wildfly/extension/nosql/cdi/Neo4jExtension.java#L172