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

[Jesper Pedersen]

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.

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.

Best regards,
  Jesper