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

[Scott Marlow]

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
>