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