update on WildFly NoSQL prototype integration...

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration...

Gytis Trikleris-2
Scott,

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

Gytis

On 19 Jul 2016, at 19:36, Scott Marlow <[hidden email]> wrote:



On 07/19/2016 10:49 AM, Scott Marlow wrote:


On 07/19/2016 04:17 AM, Emmanuel Bernard wrote:
On Mon 2016-07-18 12:20, Scott Marlow wrote:
Thanks for the feedback.

On 07/18/2016 09:24 AM, Emmanuel Bernard wrote:
I'm lost.

What is the expected code a developer will write ?

If that' something along the lines of:

jta.beginTx() // declaratively or imperatively
neo4j.beginTx()
...
neo4j.commit()
jta.commit() //declaratively or imperatively

They are not limited to writing the above code.  In addition, the developer
can also avoid calling neo4j.beginTx()/neo4j.commit(). Something like:

jta.beginTx() // declaratively or imperatively
session = driver.session() // internally does session.beginTransaction()
...
jta.commit() //declaratively or imperatively

The calls to neo4j.beginTx()/commit() are ignored.

The choice of ignoring those calls, is made against the alternative of
throwing an exception.  The reason for ignoring the neo4j transactional
calls, is to be more compatible with existing ne04j code that may be using
the neo4j transactional code, with the goal that the JTA transaction
controls the underlying ne04j transaction.  Neo4j transactional code also
runs the statements against the neo4j transaction class, instead of the
neo4j session class.

You mean having existing code work with the new JTA transaction net?
I don't think you can safely support that. What if the code does

@Transactional
public void doThings() {
  session = drive.session();
  session.beginTransaction();
// should be:
Transaction transaction = session.beginTransaction();
  try {
      // do things
  catch (Exception e) {
      // swallow exception because we will fix things
      session.rollback();
// should be:
         transaction.failure();
      session.beginTransaction();
         transaction = session.beginTransaction();
      // do something else
      session.commit();
   }
}

Such an existing code won't work if JTA in involved and
session.beginTrnasaction() / commit() are ignored.

With the current prototype, the above existing code won't work as
originally intended (with regard to what the original developer had in
mind) with JTA enlistment.


So only code written with the idea of the JTA net in mind will be safe.

Clearly, any existing neo4j code that expects to fail the current neo4j
transaction, then start a new neo4j transaction to fix things, will not
work in the JTA net.  As the fixing of things in the JTA net, needs to
occur before marking the JTA transaction for rollback only *or* by
fixing things after the JTA transaction rolls back.

Are there any other holes that come to mind, with regard to existing
neo4j transaction code that won't work as original intended in the JTA net?



then I find it very user unfriendly to force the code to call both Tx
APIs. It should be one or the other.

Do you really want to rewrite your neo4j code to avoid the neo4j tx APIs
when enlisted into a JTA transaction?  Or should the neo4j tx API calls be
ignored when enlisted into a JTA transaction (as we are doing now)?

See my above example of already existing code.

For new code that you want to run both in SE and Wildfly, that's an
interesting question but how would you do it in practice? A try catch
but rethrowing the exception in case JTA is involved and needs to be
notified of the tx rollback?

The developer could rewrite their "workaround tx failure" code to avoid
further calls to the neo4j tx api, but this is kind of bad as they only
should do this when the neo4j transaction is enlisted into the JTA
transaction, but not when enlistment is disabled.  Some neo4j connection
profiles will be configured to allow JTA enlistment (transaction=1pc)
and some will be configured to not allow JTA enlistment
(transaction=none), so we can expect common application code will likely
be reused for both JTA + non-JTA.  Seems to me that SE is always the
same as the WildFly neo4j connection profile with "transaction=none", so
we have the same problem with SE + WildFly, trying to run the same user
code that is expected to work with JTA enlistment (neo4j connection
profile has "transaction=1pc").

I don't know of any CDI magic that helps, as if we add support for
inject of a javax.transaction.TransactionScoped neo4j session, that
works the same as a session obtained from Driver.session().

I'm interested to see concrete code because if doable, it will have lots
of constraints and be limited to very specific patterns of code I think.
But again, let's show each other code.

I found some examples in the Neo4j Java driver unit tests.  I started a 
gist [1] that lists a few of the test cases that I thought were 
interesting for this discussion about "compatibility of existing Neo4j 
tx handling code in the JTA net".

In actual applications, the use cases will not be so simple.  Instead, 
we will see many different patterns mixed over several lines of 
application library code, however, each unit case noted is presenting a 
different example that would probably not run as is, when enlisted in a 
JTA transaction.

This doesn't mean it is bad to enlist Neo4j transactions into a JTA 
transaction, it just means that it is bad assume that a Neo4j tx works 
the same when enlisted in a JTA transaction.

I think that a challenge here for us, is to deduce what our rules should 
be when enlisting Neo4j transactions into a JTA transaction, with regard 
to what the application can expect and shouldn't expect.

Scott

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


That should help us explore the compatibility with existing code idea
and pick which approach to use (e.g. whether explicit neo4j transaction
use in a JTA enlisted transaction should throw an exception or ignore
the explicit transaction use as we are doing now in the prototype).

Should we also post on https://groups.google.com/forum/#!forum/neo4j to
ask for input on JTA enlistment?


Emmanuel

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration...

Jesper Pedersen-2
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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration...

Scott Marlow
In reply to this post by Gytis Trikleris-2


On 07/20/2016 06:02 AM, Gytis Trikleris wrote:
> Scott,
>
> 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.

I'm trying to understand how the description in 3.2.1.1 applies to
Neo4jXAResourceImpl (implements org.jboss.tm.LastResource and not
com.arjuna.ats.jta.resources.LastResourceCommitOptimisation).


By default, will WildFly allow more than one org.jboss.tm.LastResource
to be enlisted into the JTA transaction at a time?  When you say above
that its possible for two Neo4jXAResourceImpl's to be injected, would
that only be if com.arjuna.ats.jta.allowMultipleLastResources is changed
to true?

Thanks for pointing this case out!

Scott

>
> Gytis
>
>> On 19 Jul 2016, at 19:36, Scott Marlow <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>
>>
>> On 07/19/2016 10:49 AM, Scott Marlow wrote:
>>>
>>>
>>> On 07/19/2016 04:17 AM, Emmanuel Bernard wrote:
>>>> On Mon 2016-07-18 12:20, Scott Marlow wrote:
>>>>> Thanks for the feedback.
>>>>>
>>>>> On 07/18/2016 09:24 AM, Emmanuel Bernard wrote:
>>>>>> I'm lost.
>>>>>>
>>>>>> What is the expected code a developer will write ?
>>>>>>
>>>>>> If that' something along the lines of:
>>>>>>
>>>>>> jta.beginTx() // declaratively or imperatively
>>>>>> neo4j.beginTx()
>>>>>> ...
>>>>>> neo4j.commit()
>>>>>> jta.commit() //declaratively or imperatively
>>>>>
>>>>> They are not limited to writing the above code.  In addition, the
>>>>> developer
>>>>> can also avoid calling neo4j.beginTx()/neo4j.commit(). Something like:
>>>>>
>>>>> jta.beginTx() // declaratively or imperatively
>>>>> session = driver.session() // internally does
>>>>> session.beginTransaction()
>>>>> ...
>>>>> jta.commit() //declaratively or imperatively
>>>>>
>>>>> The calls to neo4j.beginTx()/commit() are ignored.
>>>>>
>>>>> The choice of ignoring those calls, is made against the alternative of
>>>>> throwing an exception.  The reason for ignoring the neo4j transactional
>>>>> calls, is to be more compatible with existing ne04j code that may
>>>>> be using
>>>>> the neo4j transactional code, with the goal that the JTA transaction
>>>>> controls the underlying ne04j transaction.  Neo4j transactional
>>>>> code also
>>>>> runs the statements against the neo4j transaction class, instead of the
>>>>> neo4j session class.
>>>>
>>>> You mean having existing code work with the new JTA transaction net?
>>>> I don't think you can safely support that. What if the code does
>>>>
>>>> @Transactional
>>>> public void doThings() {
>>>>   session = drive.session();
>>>>   session.beginTransaction();
>>> // should be:
>>> Transaction transaction = session.beginTransaction();
>>>>   try {
>>>>       // do things
>>>>   catch (Exception e) {
>>>>       // swallow exception because we will fix things
>>>>       session.rollback();
>>> // should be:
>>>          transaction.failure();
>>>>       session.beginTransaction();
>>>          transaction = session.beginTransaction();
>>>>       // do something else
>>>>       session.commit();
>>>>    }
>>>> }
>>>>
>>>> Such an existing code won't work if JTA in involved and
>>>> session.beginTrnasaction() / commit() are ignored.
>>>
>>> With the current prototype, the above existing code won't work as
>>> originally intended (with regard to what the original developer had in
>>> mind) with JTA enlistment.
>>>
>>>>
>>>> So only code written with the idea of the JTA net in mind will be safe.
>>>
>>> Clearly, any existing neo4j code that expects to fail the current neo4j
>>> transaction, then start a new neo4j transaction to fix things, will not
>>> work in the JTA net.  As the fixing of things in the JTA net, needs to
>>> occur before marking the JTA transaction for rollback only *or* by
>>> fixing things after the JTA transaction rolls back.
>>>
>>> Are there any other holes that come to mind, with regard to existing
>>> neo4j transaction code that won't work as original intended in the
>>> JTA net?
>>>
>>>>
>>>>>>
>>>>>> then I find it very user unfriendly to force the code to call both Tx
>>>>>> APIs. It should be one or the other.
>>>>>
>>>>> Do you really want to rewrite your neo4j code to avoid the neo4j tx
>>>>> APIs
>>>>> when enlisted into a JTA transaction?  Or should the neo4j tx API
>>>>> calls be
>>>>> ignored when enlisted into a JTA transaction (as we are doing now)?
>>>>
>>>> See my above example of already existing code.
>>>>
>>>> For new code that you want to run both in SE and Wildfly, that's an
>>>> interesting question but how would you do it in practice? A try catch
>>>> but rethrowing the exception in case JTA is involved and needs to be
>>>> notified of the tx rollback?
>>>
>>> The developer could rewrite their "workaround tx failure" code to avoid
>>> further calls to the neo4j tx api, but this is kind of bad as they only
>>> should do this when the neo4j transaction is enlisted into the JTA
>>> transaction, but not when enlistment is disabled.  Some neo4j connection
>>> profiles will be configured to allow JTA enlistment (transaction=1pc)
>>> and some will be configured to not allow JTA enlistment
>>> (transaction=none), so we can expect common application code will likely
>>> be reused for both JTA + non-JTA.  Seems to me that SE is always the
>>> same as the WildFly neo4j connection profile with "transaction=none", so
>>> we have the same problem with SE + WildFly, trying to run the same user
>>> code that is expected to work with JTA enlistment (neo4j connection
>>> profile has "transaction=1pc").
>>>
>>> I don't know of any CDI magic that helps, as if we add support for
>>> inject of a javax.transaction.TransactionScoped neo4j session, that
>>> works the same as a session obtained from Driver.session().
>>>
>>>> I'm interested to see concrete code because if doable, it will have lots
>>>> of constraints and be limited to very specific patterns of code I think.
>>>> But again, let's show each other code.
>>
>> I found some examples in the Neo4j Java driver unit tests.  I started a
>> gist [1] that lists a few of the test cases that I thought were
>> interesting for this discussion about "compatibility of existing Neo4j
>> tx handling code in the JTA net".
>>
>> In actual applications, the use cases will not be so simple.  Instead,
>> we will see many different patterns mixed over several lines of
>> application library code, however, each unit case noted is presenting a
>> different example that would probably not run as is, when enlisted in a
>> JTA transaction.
>>
>> This doesn't mean it is bad to enlist Neo4j transactions into a JTA
>> transaction, it just means that it is bad assume that a Neo4j tx works
>> the same when enlisted in a JTA transaction.
>>
>> I think that a challenge here for us, is to deduce what our rules should
>> be when enlisting Neo4j transactions into a JTA transaction, with regard
>> to what the application can expect and shouldn't expect.
>>
>> Scott
>>
>> [1] https://gist.github.com/scottmarlow/2779d21653e8466d85e38c1d62d4bb1e
>>
>>>
>>> That should help us explore the compatibility with existing code idea
>>> and pick which approach to use (e.g. whether explicit neo4j transaction
>>> use in a JTA enlisted transaction should throw an exception or ignore
>>> the explicit transaction use as we are doing now in the prototype).
>>>
>>> Should we also post on https://groups.google.com/forum/#!forum/neo4j
>>> <https://groups.google.com/forum/#%21forum/neo4j> to
>>> ask for input on JTA enlistment?
>>>
>>>>
>>>> Emmanuel
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email] <mailto:[hidden email]>
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email] <mailto:[hidden email]>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration...

Gytis Trikleris-2
The specific marker interface for it is overridable. See https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/service/JTAEnvironmentBeanService.java#L58 where it is set to org.jboss.tm.LastResource.
No, by default it will not add the second resource but it can be allowed by changing the config. However, it will still print the warning.

Gytis

> On 20 Jul 2016, at 14:59, Scott Marlow <[hidden email]> wrote:
>
>
>
> On 07/20/2016 06:02 AM, Gytis Trikleris wrote:
>> Scott,
>>
>> 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.
>
> I'm trying to understand how the description in 3.2.1.1 applies to Neo4jXAResourceImpl (implements org.jboss.tm.LastResource and not com.arjuna.ats.jta.resources.LastResourceCommitOptimisation).
>
>
> By default, will WildFly allow more than one org.jboss.tm.LastResource to be enlisted into the JTA transaction at a time?  When you say above that its possible for two Neo4jXAResourceImpl's to be injected, would that only be if com.arjuna.ats.jta.allowMultipleLastResources is changed to true?
>
> Thanks for pointing this case out!
>
> Scott
>
>>
>> Gytis
>>
>>> On 19 Jul 2016, at 19:36, Scott Marlow <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>
>>>
>>> On 07/19/2016 10:49 AM, Scott Marlow wrote:
>>>>
>>>>
>>>> On 07/19/2016 04:17 AM, Emmanuel Bernard wrote:
>>>>> On Mon 2016-07-18 12:20, Scott Marlow wrote:
>>>>>> Thanks for the feedback.
>>>>>>
>>>>>> On 07/18/2016 09:24 AM, Emmanuel Bernard wrote:
>>>>>>> I'm lost.
>>>>>>>
>>>>>>> What is the expected code a developer will write ?
>>>>>>>
>>>>>>> If that' something along the lines of:
>>>>>>>
>>>>>>> jta.beginTx() // declaratively or imperatively
>>>>>>> neo4j.beginTx()
>>>>>>> ...
>>>>>>> neo4j.commit()
>>>>>>> jta.commit() //declaratively or imperatively
>>>>>>
>>>>>> They are not limited to writing the above code.  In addition, the
>>>>>> developer
>>>>>> can also avoid calling neo4j.beginTx()/neo4j.commit(). Something like:
>>>>>>
>>>>>> jta.beginTx() // declaratively or imperatively
>>>>>> session = driver.session() // internally does
>>>>>> session.beginTransaction()
>>>>>> ...
>>>>>> jta.commit() //declaratively or imperatively
>>>>>>
>>>>>> The calls to neo4j.beginTx()/commit() are ignored.
>>>>>>
>>>>>> The choice of ignoring those calls, is made against the alternative of
>>>>>> throwing an exception.  The reason for ignoring the neo4j transactional
>>>>>> calls, is to be more compatible with existing ne04j code that may
>>>>>> be using
>>>>>> the neo4j transactional code, with the goal that the JTA transaction
>>>>>> controls the underlying ne04j transaction.  Neo4j transactional
>>>>>> code also
>>>>>> runs the statements against the neo4j transaction class, instead of the
>>>>>> neo4j session class.
>>>>>
>>>>> You mean having existing code work with the new JTA transaction net?
>>>>> I don't think you can safely support that. What if the code does
>>>>>
>>>>> @Transactional
>>>>> public void doThings() {
>>>>>  session = drive.session();
>>>>>  session.beginTransaction();
>>>> // should be:
>>>> Transaction transaction = session.beginTransaction();
>>>>>  try {
>>>>>      // do things
>>>>>  catch (Exception e) {
>>>>>      // swallow exception because we will fix things
>>>>>      session.rollback();
>>>> // should be:
>>>>         transaction.failure();
>>>>>      session.beginTransaction();
>>>>         transaction = session.beginTransaction();
>>>>>      // do something else
>>>>>      session.commit();
>>>>>   }
>>>>> }
>>>>>
>>>>> Such an existing code won't work if JTA in involved and
>>>>> session.beginTrnasaction() / commit() are ignored.
>>>>
>>>> With the current prototype, the above existing code won't work as
>>>> originally intended (with regard to what the original developer had in
>>>> mind) with JTA enlistment.
>>>>
>>>>>
>>>>> So only code written with the idea of the JTA net in mind will be safe.
>>>>
>>>> Clearly, any existing neo4j code that expects to fail the current neo4j
>>>> transaction, then start a new neo4j transaction to fix things, will not
>>>> work in the JTA net.  As the fixing of things in the JTA net, needs to
>>>> occur before marking the JTA transaction for rollback only *or* by
>>>> fixing things after the JTA transaction rolls back.
>>>>
>>>> Are there any other holes that come to mind, with regard to existing
>>>> neo4j transaction code that won't work as original intended in the
>>>> JTA net?
>>>>
>>>>>
>>>>>>>
>>>>>>> then I find it very user unfriendly to force the code to call both Tx
>>>>>>> APIs. It should be one or the other.
>>>>>>
>>>>>> Do you really want to rewrite your neo4j code to avoid the neo4j tx
>>>>>> APIs
>>>>>> when enlisted into a JTA transaction?  Or should the neo4j tx API
>>>>>> calls be
>>>>>> ignored when enlisted into a JTA transaction (as we are doing now)?
>>>>>
>>>>> See my above example of already existing code.
>>>>>
>>>>> For new code that you want to run both in SE and Wildfly, that's an
>>>>> interesting question but how would you do it in practice? A try catch
>>>>> but rethrowing the exception in case JTA is involved and needs to be
>>>>> notified of the tx rollback?
>>>>
>>>> The developer could rewrite their "workaround tx failure" code to avoid
>>>> further calls to the neo4j tx api, but this is kind of bad as they only
>>>> should do this when the neo4j transaction is enlisted into the JTA
>>>> transaction, but not when enlistment is disabled.  Some neo4j connection
>>>> profiles will be configured to allow JTA enlistment (transaction=1pc)
>>>> and some will be configured to not allow JTA enlistment
>>>> (transaction=none), so we can expect common application code will likely
>>>> be reused for both JTA + non-JTA.  Seems to me that SE is always the
>>>> same as the WildFly neo4j connection profile with "transaction=none", so
>>>> we have the same problem with SE + WildFly, trying to run the same user
>>>> code that is expected to work with JTA enlistment (neo4j connection
>>>> profile has "transaction=1pc").
>>>>
>>>> I don't know of any CDI magic that helps, as if we add support for
>>>> inject of a javax.transaction.TransactionScoped neo4j session, that
>>>> works the same as a session obtained from Driver.session().
>>>>
>>>>> I'm interested to see concrete code because if doable, it will have lots
>>>>> of constraints and be limited to very specific patterns of code I think.
>>>>> But again, let's show each other code.
>>>
>>> I found some examples in the Neo4j Java driver unit tests.  I started a
>>> gist [1] that lists a few of the test cases that I thought were
>>> interesting for this discussion about "compatibility of existing Neo4j
>>> tx handling code in the JTA net".
>>>
>>> In actual applications, the use cases will not be so simple.  Instead,
>>> we will see many different patterns mixed over several lines of
>>> application library code, however, each unit case noted is presenting a
>>> different example that would probably not run as is, when enlisted in a
>>> JTA transaction.
>>>
>>> This doesn't mean it is bad to enlist Neo4j transactions into a JTA
>>> transaction, it just means that it is bad assume that a Neo4j tx works
>>> the same when enlisted in a JTA transaction.
>>>
>>> I think that a challenge here for us, is to deduce what our rules should
>>> be when enlisting Neo4j transactions into a JTA transaction, with regard
>>> to what the application can expect and shouldn't expect.
>>>
>>> Scott
>>>
>>> [1] https://gist.github.com/scottmarlow/2779d21653e8466d85e38c1d62d4bb1e
>>>
>>>>
>>>> That should help us explore the compatibility with existing code idea
>>>> and pick which approach to use (e.g. whether explicit neo4j transaction
>>>> use in a JTA enlisted transaction should throw an exception or ignore
>>>> the explicit transaction use as we are doing now in the prototype).
>>>>
>>>> Should we also post on https://groups.google.com/forum/#!forum/neo4j
>>>> <https://groups.google.com/forum/#%21forum/neo4j> to
>>>> ask for input on JTA enlistment?
>>>>
>>>>>
>>>>> Emmanuel
>>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email] <mailto:[hidden email]>
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email] <mailto:[hidden email]>
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration...

Scott Marlow
In reply to this post by Jesper Pedersen-2


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
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: (transaction enlistment for ACID but none for BASE...) update on WildFly NoSQL prototype integration...

Emmanuel Bernard
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.

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.

Emmanuel
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: (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
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
123