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

[Scott Marlow]

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
>