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

[Scott Marlow]

On 07/21/2016 04:13 AM, Emmanuel Bernard wrote:
> On Wed 2016-07-20 11:51, Scott Marlow wrote:
>  >
>>> 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.
>
> That's not my preferred advantage to be honest.
> My favorite is that people can use the @Transactional programming model
> of EJB/CDI like they do for RDBMSes. That's a huge win.

Excellent that we are arguing over our preferred advantage, I like yours 
also, as well as mine! :-)

>
> What we are questioning here, is transparently ignoring explicit
> "native" tx API calls when the JTA binding is in effect. It looked nice
> on paper but has serious corner cases. So simpler might be better here.

After reviewing some of the example code in the Neo4j Java driver unit 
tests [1], I'm leaning towards agreeing that throwing a RuntimeException 
is the better (strict) approach now.  If we are wrong, it is easy for us 
to later add an option, to enable (lenient) proxying of the various 
"native" tx API calls when the JTA binding is in effect.

We can revisit this once there is user demand for the various "native" 
tx API calls.

Scott

[1] https://gist.github.com/scottmarlow/2779d21653e8466d85e38c1d62d4bb1e