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?

In the one using CMT, there are also calls to the Neo4j TX API which apparently are ignored. What's the rationale behind that? Wouldn't it make more sense to raise an exception, similar to when EntityManager#getTransaction() is invoked for a JTA entity manager?

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?

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

I hope that'd make sense for actually transactional stores such as Neo4j, for non-TX stores such as MongoDB thinks look different.

--Gunnar



2016-07-13 16:25 GMT+01:00 Scott Marlow <smarlow@redhat.com>:


On 07/13/2016 10:44 AM, Jesper Pedersen wrote:
> On 07/12/2016 11:36 AM, Scott Marlow wrote:
>>> 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.
>>
>> I pushed an update [1] that includes auto closing the session, when the
>> transaction ends.
>>
>> I didn't add a Synchronization yet, to handle closing the session when
>> the transaction manager doesn't call XAResourceWrapper.commit/rollback.
>> I agree that will introduce an extra layer of safety to ensure that
>> resources are closed.
>>
>
> I think you can use the XAResource instance for that at the moment.

Yes, we are doing this currently.

>
>>>
>>> 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.
>>
>> Attempts to call Neo4j transaction/session "close", within the JTA
>> transaction are ignored.  How about calls to "close" after the JTA
>> transaction ends, should they also be ignored?
>
> Hopefully the underlying implementation will ignore multiple close()
> calls, and throw an exception on any other call.

isOpen is currently returning false instead of throwing an exception.
We are ignoring multiple close() calls and do throw an exception on any
other call.

>
> You will have to test the behaviour of each NoSQL store.
>
>>  Is there a JCA
>> equivalent of ignoring "close" after the transaction ends?  I think that
>> Hibernate ORM is or was, closing DataSource's after the transaction
>> ends, so I assume that JCA ignores "close" after the JTA transaction
>> ends.
>>
>
> You probably mean Connection.close() -- if all connections are closed in
> afterCompletion then the connection is returned to the pool. Otherwise,
> it waits until ref count becomes 0, e.g. c.close() after the transaction
> has ended.
>
> http://www.ironjacamar.org/doc/roadto12/txtracking.html
>
> Best regards,
>  Jesper
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev