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

[Jesper Pedersen]

Hi,

On 07/08/2016 12:24 PM, Scott Marlow wrote:
> The NoSQL prototype now has transaction enlistment for Neo4j (one phase
> wrapper).
>
> Test example link [1] shows a CMT test bean method

You should add a comment that tx.success() / tx.failure() is tied to the 
out-come of the JTA transaction. And tx.close() is done in afterCompletion.

> and [2] shows a BMT test bean method.
>

This test case highlights the problem of checking for enlistment in 2 
places, as the Session is obtained before the transaction is started, 
and there is no way to get the session reference from the transaction 
instance.

So, you can manage the transaction lifecycle, but not the session lifecycle.

> 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.

As you are enlisting the Neo4J resources into the transaction, I think 
that you should define driver.session() as the enlistment barrier, and 
therefore also close the session in afterCompletion.

That makes it more clear in what scenarios the resources are managed.

In JDBC you inject the DataSource instance, and obtain a Connection, so 
it would be parallel to this case Driver vs. Session.

This means that people needs to be more careful in the BMT case to get 
the Session within an active transaction. JCA has 
CachedConnectionManager to verify these cases, so you could add a 
similar concept.

Best regards,
  Jesper