10:51 a.m.
On 07/20/2016 08:53 AM, Jesper Pedersen wrote:
Hi,
On 07/20/2016 06:02 AM, Gytis Trikleris wrote:
> I think that this wouldn’t be a common case, but it is still possible
> that user could inject drivers from two different profiles and invoke
> them in the same transaction. In this case two Neo4jXAResourceImpl
> instances would be enlisted to the transaction and that is not a
> recommended use case because atomicity cannot be guaranteed. There is
> a bit more info about it in section 3.2.1.1. of
> http://narayana.io/docs/product/index.html
> <http://narayana.io/docs/product/index.html>;.
>
This is precisely the same as the <data-source jta="false|true">
discussion.
For <data-source jta="false"> (transaction="none"), users will
need to
manage the transactional resource of the NoSQL store themselves, e.g.
how apps are coded today using session.beginTransaction() and so on.
Not exactly, the application can also use compensation with the
connection profile set to transaction=none.
So, choices for Neo4j are really, use compensating transactions with JTA
or 1pc with JTA or none.
For the BASE NoSQL databases, the only option is to use compensating
transactions with JTA or none.
NoSQL connection profiles are not data-source.
As the store isn't enlisted in the JTA transaction you can inject as
many as you want. However, the ACID properties of the store is tied to
the application code, and not the out-come of the JTA transaction.
This is the same as doing Connection.setAutoCommit(false) and
Connection.commit() in JDBC. Yes, there are apps that need this, but
fewer each day.
For <data-source jta="true"> (transaction="1pc"), the
transactional
resource of the NoSQL store is enlisted in the JTA transaction by the
container, e.g. any application code using session.beginTransaction()
and so on are basically no-ops.
Now, the ACID properties of the store is tied to the out-come of the JTA
transaction. This means that you can remove all code regarding
transaction handling from your application and let the JTA transaction
handle it (there is a question if tx.failure() should trigger
setRollbackOnly(), but that is a separate matter). Like DataSource you
only get to inject 1 instance, otherwise it is <xa-data-source> and 2pc.
Yes, it is a different way of doing NoSQL apps, since the transactional
scope is tied to JTA, but it also provides a much simpler way to do
business logic flow. So, this will take some time for people to get used
to, but people saw the benefit of not handling transactional integration
of JDBC themselves (Go JCA !).
The transactional properties will be different in each NoSQL store,
f.ex. in Neo4J tx.success() / tx.failure() doesn't do anything before
tx.close() is called. So having transaction="1pc" (and "2pc") is a
way
to unify transactional integration across different NoSQL stores.
We are taking a closer look at different Neo4j examples, to better
understand the pros/cons of allowing applications to call
tx.success/tx.failure in the JTA transaction.
I think that the advantage of enlisting Neo4j into a JTA transaction is
that it makes it easier for the application developer to coordinate
updating multiple resources within the same transaction.
Best regards,
Jesper