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

[Scott Marlow]

I think that we will move forward now and prototype the transaction 
enlistment for ACID NoSQL databases.  This is important to nail down 
now, as we would like forward application compatibility.  We need to 
choose now, whether MySLSB.myMethod() performs the Neo4j database update 
immediately when (#4) tx.close() is called or when the JTA transaction 
completes.  By now, I mean that we need to decide before a release of 
WildFly that contains the NoSQL integration is released, so that we know 
that future releases will be compatible.

I don't think that transaction enlistment should be allowed for BASE 
NoSQL databases, which is why I mentioned ACID above.  With BASE 
databases, the application code is responsible for dealing with dirty 
data.  As such, I think it would be misleading to enlist BASE operations 
into a JTA transaction.  This means that BASE NoSQL database profiles 
will not allow 1-phase/2-phase transaction attribute to be specified.

We started to write some design notes [1] for NoSQL integration.  We 
will update the design notes after hearing more feedback on the above.

Scott

[1] https://developer.jboss.org/wiki/DesignNotesForNoSQLIntegrationOnWildFly

On 05/10/2016 11:06 AM, Jesper Pedersen wrote:
>> Any links to existing IronJacamar code to share here?  I think that we
>> could prototype new transaction enlistment handling code, based on what
>> we currently have.
>>
>
> The IronJacamar code is here for Narayana:
>
> https://github.com/ironjacamar/ironjacamar/tree/master/core/src/main/java/org/ironjacamar/core/tx/narayana
>
>
> However, that is based on the Java EE Connector Architecture
> specification, so we have a *much* easier job.
>
> Lets take an example from the NoSQL world using Neo4J:
>
> http://neo4j.com/docs/api/java-driver/current/org/neo4j/driver/v1/Driver.html
>
>
> ...neo4j.LocalXAResource implements XAResource, org.jboss.tm.LastResource
>
>  public void start(Xid xid, int flags) throws XAException {
>    tx = session.beginTransaction();
>  }
>
>  public void commit(Xid xid, boolean onePhase) throws XAException {
>    tx.success();
>  }
>
>  public void rollback(Xid xid) throws XAException {
>    tx.failure();
>  }
>
> And the app, f.ex. in a SLSB method
>
> public class MySLSB ...
>
>   @Resource(mappedName="java:jboss/nosql/neo4j")
>   private Driver neo4j;
>
>   public void myMethod() {
> #1   Session s = neo4j.createSession();
>      s.run( "CREATE (n {name:'Bob'})" );
>
> #2   Transaction tx = s.beginTransaction();
>      tx.run( "CREATE (n {name:'Alice'})" );
>      tx.run( "CREATE (n {name:'Tina'})" );
>
> #3   tx.success();
>
> #4   tx.close();
> #5   s.close();
> #6   neo4j.close();
>   }
>
> However, as you can see there are a number of hidden things going on
> here if ".../neo4j" is deployed as "transaction=1phase".
>
> #1: Here you have to intercept the call, create the LocalXAResource
> instance and enlist it in the active transaction
>
> #2: Here you have to a delegator instance that only executes the run()
> calls
>
> #3: No-op call, happens upon EE transaction completion
>
> #4: No-op call. happens upon EE transaction completion
>
> #5: No-op call, happens in an enlisted Synchronization instance
> (afterCompletion) (done in #1 too)
>
> #6: No-op call, handled by subsystem
>
> The value-add is that #3 is tied into the overall EE transaction.
>
> If ".../neo4j" is deployed as "transaction=none", then all calls are on
> the "real" Neo4J objects.
>
> As you can see it isn't as simple as it may appear, and application flow
> could be different from what the developer expects, as #3 could be a
> real tx.failure() call in case of MARKED_FOR_ROLLBACK.
>
> There are def pros/cons of doing tx enlistment for this area...