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

[Emmanuel Bernard]

I haven't looked in detail but +1 to what Gunnar says. 
I would add that the WF Neo4j confuguration should have an option to either treat Neo4j as a JTA enlisted source or not. 
In the former, the behavior would be as Gunnar suggests. In the latter, direct Neo4j session creation and transaction would be used. 

> On 13 juil. 2016, at 19:16, Gunnar Morling <gunnar at hibernate.org> 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?
> 
> 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160713/2b0e17a9/attachment.html