12:39 p.m.
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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev