On Mon 2016-07-18 12:20, Scott Marlow wrote:
Thanks for the feedback.
On 07/18/2016 09:24 AM, Emmanuel Bernard wrote:
> I'm lost.
>
> What is the expected code a developer will write ?
>
> If that' something along the lines of:
>
> jta.beginTx() // declaratively or imperatively
> neo4j.beginTx()
> ...
> neo4j.commit()
> jta.commit() //declaratively or imperatively
They are not limited to writing the above code. In addition, the developer
can also avoid calling neo4j.beginTx()/neo4j.commit(). Something like:
jta.beginTx() // declaratively or imperatively
session = driver.session() // internally does session.beginTransaction()
...
jta.commit() //declaratively or imperatively
The calls to neo4j.beginTx()/commit() are ignored.
The choice of ignoring those calls, is made against the alternative of
throwing an exception. The reason for ignoring the neo4j transactional
calls, is to be more compatible with existing ne04j code that may be using
the neo4j transactional code, with the goal that the JTA transaction
controls the underlying ne04j transaction. Neo4j transactional code also
runs the statements against the neo4j transaction class, instead of the
neo4j session class.
You mean having existing code work with the new JTA transaction net?
I don't think you can safely support that. What if the code does
@Transactional
public void doThings() {
session = drive.session();
session.beginTransaction();
try {
// do things
catch (Exception e) {
// swallow exception because we will fix things
session.rollback();
session.beginTransaction();
// do something else
session.commit();
}
}
Such an existing code won't work if JTA in involved and
session.beginTrnasaction() / commit() are ignored.
So only code written with the idea of the JTA net in mind will be safe.
>
> then I find it very user unfriendly to force the code to call both Tx
> APIs. It should be one or the other.
Do you really want to rewrite your neo4j code to avoid the neo4j tx APIs
when enlisted into a JTA transaction? Or should the neo4j tx API calls be
ignored when enlisted into a JTA transaction (as we are doing now)?
See my above example of already existing code.
For new code that you want to run both in SE and Wildfly, that's an
interesting question but how would you do it in practice? A try catch
but rethrowing the exception in case JTA is involved and needs to be
notified of the tx rollback?
I'm interested to see concrete code because if doable, it will have lots
of constraints and be limited to very specific patterns of code I think.
But again, let's show each other code.
Emmanuel