- Maybe refactor from org.jboss.as to org.wildfly - I think you can leave out the "subsystem" part of the package name

Hi, On 05/04/2016 02:16 PM, Scott Marlow wrote: > Below is an update on the WildFly NoSQL integration project. The goal > is for deployed applications to have access to NoSQL databases (via > Hibernate OGM or native APIs). Items 1-4, should be finished in our > first pass, with as much of the others items as we can do as well. > Some general comments: - Good start :) - Maybe refactor from org.jboss.as to org.wildfly

- Maybe use version identifiers in the package name since NoSQL APIs change a lot

- Add some additional asserts to the test cases to verify input / output from the stores > 1. connection management will deal with obtaining NoSQL connections for > application use. > > - borrow/share Hibernate OGM connection configuration setup code > - authentication integration > - support transport level security > Connection management is a huge area to tackle. I think it is best to start with what each NoSQL implementation offer.

The big question is if the connections should be truly managed which would give the option to no-op dangerous API calls out. There aren't any spec requirements for this, so it is really a matter of how the APIs should be presented.

You may have to proxy some of the classes in order to pass the security information into the stores. I think people would expect to use WildFly security domains for this (SubjectFactory/Subject).

> 2. CDI programming simplifications will make it easy to inject NoSQL > data into your application classes. > > - https://github.com/antoinesd/javaee-nosql is initial idea > > 3. You will easily get a native NoSQL connection from the specified > NoSQL profile and use the native NOSQL (Cassandra/MongoDB/other) API in > your application. > I think this is key, as the APIs change almost per release.

> 4. You will also be able to easily use Hibernate OGM with the defined > NoSQL profiles (exactly how is TBD but will be awesome :-). > - Hibernate OGM static module is included. > - need to align with OGM dependencies (e.g. Hibernate ORM + other > dependencies). > - as mentioned above, OGM already has some connection setup code, > which might be good to share for WildFly + standalone NoSQL use. > - once WildFly has a common NoSQLSource (not a DataSource) that OGM > can use, OGM will be enhanced to use it. > > 5. How best for the WildFly NoSQL subsystem to be optional? > - Is it enough to not run the wildfly/testsuite/nosql tests by default? > - Or do we need to start a separate https://github.com/wildfly/nosql > project for the NoSQL subsystems? > > 6. transaction enlistment > This will vary for each store, and there are many loopholes that you may want to plug, f.ex. sharing a connection between 2 transactions. For 1-phase, you will have to insert a LocalXAResource instance into the transaction when the "connection" is obtained, and return it on the boundary (afterCompletion). Same deal for 2-phase basically. The LocalXAResource implementation will of course be different for each store. You may want a transaction option for the stores that supports this such that people can choose the "level" of enlistment (ala jta="false"). One task I see is that people will have access to the transactional methods in the API, and you don't want them to call these methods in their apps unless the transaction setting allows this. I think you can leave out the corner-cases in the 1st iteration, like deferred enlistment (get connection, start transaction). > 7. compensating transactions > Another huge area. I would let the use-cases from WildFly/Swarm drive this. A simple way to start is to have a SPI that apps can implement in case the transaction is MARKED_FOR_ROLLBACK (hooks to an enlisted XAResource).

> 8. runtime application monitoring > As each store is different I would only look into what the subsystem can expose, plus whatever the store can display.

> > 7. compensating transactions > > > > Another huge area. > > I would let the use-cases from WildFly/Swarm drive this. > > A simple way to start is to have a SPI that apps can implement in case > the transaction is MARKED_FOR_ROLLBACK (hooks to an enlisted > XAResource). > > > We implemented those in IJ (even if in much more standard JCA > environment), and maybe we could share and eventually copy/paste some > code. Check out "MongoDB integration test with compensating transactions" https://github.com/scottmarlow/wildfly/commit/9bd67964a9259416add73cac473..., which is a good start. We can work forward from what we have and ideas from IJ.

Hi, On 05/04/2016 02:16 PM, Scott Marlow wrote: > Below is an update on the WildFly NoSQL integration project. The goal > is for deployed applications to have access to NoSQL databases (via > Hibernate OGM or native APIs). Items 1-4, should be finished in our > first pass, with as much of the others items as we can do as well. > Some general comments: - Good start :) - Maybe refactor from org.jboss.as to org.wildfly

- I think you can leave out the "subsystem" part of the package name

- Maybe use version identifiers in the package name since NoSQL APIs change a lot

- Add some additional asserts to the test cases to verify input / output from the stores

> 1. connection management will deal with obtaining NoSQL connections for > application use. > > - borrow/share Hibernate OGM connection configuration setup code > - authentication integration > - support transport level security > Connection management is a huge area to tackle. I think it is best to start with what each NoSQL implementation offer.

The big question is if the connections should be truly managed which would give the option to no-op dangerous API calls out. There aren't any spec requirements for this, so it is really a matter of how the APIs should be presented. You may have to proxy some of the classes in order to pass the security information into the stores. I think people would expect to use WildFly security domains for this (SubjectFactory/Subject).

> 2. CDI programming simplifications will make it easy to inject NoSQL > data into your application classes. > > - https://github.com/antoinesd/javaee-nosql is initial idea > > 3. You will easily get a native NoSQL connection from the specified > NoSQL profile and use the native NOSQL (Cassandra/MongoDB/other) API in > your application. > I think this is key, as the APIs change almost per release. > 4. You will also be able to easily use Hibernate OGM with the defined > NoSQL profiles (exactly how is TBD but will be awesome :-). > - Hibernate OGM static module is included. > - need to align with OGM dependencies (e.g. Hibernate ORM + other > dependencies). > - as mentioned above, OGM already has some connection setup code, > which might be good to share for WildFly + standalone NoSQL use. > - once WildFly has a common NoSQLSource (not a DataSource) that OGM > can use, OGM will be enhanced to use it. > > 5. How best for the WildFly NoSQL subsystem to be optional? > - Is it enough to not run the wildfly/testsuite/nosql tests by default? > - Or do we need to start a separate https://github.com/wildfly/nosql > project for the NoSQL subsystems? > > 6. transaction enlistment > This will vary for each store, and there are many loopholes that you may want to plug, f.ex. sharing a connection between 2 transactions. For 1-phase, you will have to insert a LocalXAResource instance into the transaction when the "connection" is obtained, and return it on the boundary (afterCompletion). Same deal for 2-phase basically. The LocalXAResource implementation will of course be different for each store.

You may want a transaction option for the stores that supports this such that people can choose the "level" of enlistment (ala jta="false"). One task I see is that people will have access to the transactional methods in the API, and you don't want them to call these methods in their apps unless the transaction setting allows this. I think you can leave out the corner-cases in the 1st iteration, like deferred enlistment (get connection, start transaction). > 7. compensating transactions > Another huge area. I would let the use-cases from WildFly/Swarm drive this. A simple way to start is to have a SPI that apps can implement in case the transaction is MARKED_FOR_ROLLBACK (hooks to an enlisted XAResource). > 8. runtime application monitoring > As each store is different I would only look into what the subsystem can expose, plus whatever the store can display. > 9. How soon can we make an evaluation distribution available for use on > OpenStack/OpenShift? > - Would be great if we could do some load testing with all NoSQL > components. > - Would be great if we could enable others to also test. > > 10. Are there any problems with our WildFly NoSQL subsystem injecting > MongoDatabase connections via: > > @Resource(lookup = "java:jboss/mongodb/test") MongoDatabase db; > > - No @Resource support expected for standalone Java, TBD is whether a > runtime library can be used. > - Any problems expected on other EE application servers if this > approach becomes popular? > This ties into connection management. I like what you have now for the 1st pass. > 11. WIP topic branch is at > https://github.com/scottmarlow/wildfly/tree/nosql-dev9. Note that every > once in a while, commits are squashed and pushed to nosql-devN+1. > > 12. Add proper unit tests > - multi-threaded NoSQL access to show that works at all. > - use NoSQL from different EE components (e.g. JAX-RS). > - other use cases that represent how NoSQL could be used from WildFly. > I think you can look at test cases for EE components that support @Resource.

Best regards, Jesper _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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

The NoSQL prototype now has transaction enlistment for Neo4j (one phase wrapper). Test example link [1] shows a CMT test bean method

and [2] shows a BMT test bean method.

Currently, in a JTA transaction the Neo4j Session survives ending the JTA transaction. It might be better to close the Neo4j Session when the JTA transaction ends, which would require the application to get a new Session, this would ensure that applications don't forget to close the session, with the down side that with BMT, application code would need to call the Neo4j Driver.session(), to get a new Session instance after each JTA transaction ends. After a session is closed, there is no guarantee that another session can be obtained, as the next Driver.session() may time out if the internal pool of Driver sessions, is empty and the configured time limit (neo4j.driver.acquireSessionTimeout) is exceeded (defaults to 30 seconds). So, there are costs to automatically closing Neo4j Sessions at JTA transaction end time. Although, you could say that closing the Session, after each transaction, gives other threads a change to use the Session that isn't really closed, but instead is really returned to the internal Driver sessions pool.

> As you are enlisting the Neo4J resources into the transaction, I think > that you should define driver.session() as the enlistment barrier, and > therefore also close the session in afterCompletion. I pushed an update [1] that includes auto closing the session, when the transaction ends. I didn't add a Synchronization yet, to handle closing the session when the transaction manager doesn't call XAResourceWrapper.commit/rollback. I agree that will introduce an extra layer of safety to ensure that resources are closed.

> > That makes it more clear in what scenarios the resources are managed. > > In JDBC you inject the DataSource instance, and obtain a Connection, so > it would be parallel to this case Driver vs. Session. > > This means that people needs to be more careful in the BMT case to get > the Session within an active transaction. JCA has > CachedConnectionManager to verify these cases, so you could add a > similar concept. Attempts to call Neo4j transaction/session "close", within the JTA transaction are ignored. How about calls to "close" after the JTA transaction ends, should they also be ignored?

Is there a JCA equivalent of ignoring "close" after the transaction ends? I think that Hibernate ORM is or was, closing DataSource's after the transaction ends, so I assume that JCA ignores "close" after the JTA transaction ends.

On 07/13/2016 10:44 AM, Jesper Pedersen wrote: > On 07/12/2016 11:36 AM, Scott Marlow wrote: >>> As you are enlisting the Neo4J resources into the transaction, I think >>> that you should define driver.session() as the enlistment barrier, and >>> therefore also close the session in afterCompletion. >> >> I pushed an update [1] that includes auto closing the session, when the >> transaction ends. >> >> I didn't add a Synchronization yet, to handle closing the session when >> the transaction manager doesn't call XAResourceWrapper.commit/rollback. >> I agree that will introduce an extra layer of safety to ensure that >> resources are closed. >> > > I think you can use the XAResource instance for that at the moment. Yes, we are doing this currently. > >>> >>> That makes it more clear in what scenarios the resources are managed. >>> >>> In JDBC you inject the DataSource instance, and obtain a Connection, so >>> it would be parallel to this case Driver vs. Session. >>> >>> This means that people needs to be more careful in the BMT case to get >>> the Session within an active transaction. JCA has >>> CachedConnectionManager to verify these cases, so you could add a >>> similar concept. >> >> Attempts to call Neo4j transaction/session "close", within the JTA >> transaction are ignored. How about calls to "close" after the JTA >> transaction ends, should they also be ignored? > > Hopefully the underlying implementation will ignore multiple close() > calls, and throw an exception on any other call. isOpen is currently returning false instead of throwing an exception. We are ignoring multiple close() calls and do throw an exception on any other call. > > You will have to test the behaviour of each NoSQL store. > >> Is there a JCA >> equivalent of ignoring "close" after the transaction ends? I think that >> Hibernate ORM is or was, closing DataSource's after the transaction >> ends, so I assume that JCA ignores "close" after the JTA transaction >> ends. >> > > You probably mean Connection.close() -- if all connections are closed in > afterCompletion then the connection is returned to the pool. Otherwise, > it waits until ref count becomes 0, e.g. c.close() after the transaction > has ended. > > http://www.ironjacamar.org/doc/roadto12/txtracking.html > > Best regards, > Jesper > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Hi Scott, I had a short look at the tests you pointed to; in the one using BMT, why is it that the UserTransaction *and* the Neo4j TX API are used? I'd have expected it to be only one *or* the other?

In the one using CMT, there are also calls to the Neo4j TX API which apparently are ignored.

What's the rationale behind that?

Wouldn't it make more sense to raise an exception, similar to when EntityManager#getTransaction() is invoked for a JTA entity manager?

In the CMT case, did you consider to inject the Neo4j Session instead of Driver into the bean, again akin to injection of JTA entity managers?

All in all, I'm wondering whether things couldn't be handled analogous to the usage of entity managers: * For a JTA-enabled NoSQL persistence unit, obtain the Session via injection (its lifecycle is controlled by the container and bound to the managed transaction), any manual interaction with the Neo4j TX API is forbidden, instead the container manages transactions or the user is (via UserTransaction) * For a non-JTA-enabled NoSQL persistence unit, obtain the Driver via injection, and the user is in charge of Session lifecycle and transaction control

I hope that'd make sense for actually transactional stores such as Neo4j, for non-TX stores such as MongoDB thinks look different.

--Gunnar

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

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

> > 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. > In a JTA transaction, instead of ignoring calls to org.neo4j.driver.v1.Transaction.failure(), we could call setRollbackOnly() on the JTA transaction. So, the existing neo4j code can influence a JTA rollback. IMO, this would improve our compatibility with existing neo4j.

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();

try { // do things catch (Exception e) { // swallow exception because we will fix things session.rollback();

session.beginTransaction();

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

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

>> >> 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?

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.

Emmanuel

On 19 Jul 2016, at 19:36, Scott Marlow <smarlow(a)redhat.com&gt; 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 <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 > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>

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

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.

On 20 Jul 2016, at 14:59, Scott Marlow <smarlow(a)redhat.com&gt; 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 <smarlow(a)redhat.com >> <mailto:smarlow@redhat.com>> 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 >>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >

Hi Scott, Thanks for driving this initiative! Some comments/questions inline. 2016-05-04 20:16 GMT+02:00 Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com>>: Hi, Below is an update on the WildFly NoSQL integration project. The goal is for deployed applications to have access to NoSQL databases (via Hibernate OGM or native APIs). Items 1-4, should be finished in our first pass, with as much of the others items as we can do as well. 1. connection management will deal with obtaining NoSQL connections for application use. - borrow/share Hibernate OGM connection configuration setup code - authentication integration - support transport level security Any ideas how this code sharing could look like? Hibernate OGM should still be usable without WF; So maybe there should be a separate project/repo which defines an SPI to obtain/manage connections and implementations for different NoSQL stores?

I think it'd be beneficial to define some sort of connection URL syntax which can be used in NoSQL datasource definitions: nosql:mongodb://192.168.1.100:27017[,another-host:another-port]/some_db?customParam1=xyz&customParam2=abc&...

This common syntax might do for most cases, for others it might be needed to support specialized schemes handled by store-specific SPI implementations.

Regarding pooling, many NoSQL drivers do it in one way or another, so maybe leave that to drivers, at least in the first iteration? 2. CDI programming simplifications will make it easy to inject NoSQL data into your application classes. - https://github.com/antoinesd/javaee-nosql is initial idea +1 Sounds nice. 3. You will easily get a native NoSQL connection from the specified NoSQL profile and use the native NOSQL (Cassandra/MongoDB/other) API in your application. Would you take measures to e.g. prevent closing a connection in application code?

4. You will also be able to easily use Hibernate OGM with the defined NoSQL profiles (exactly how is TBD but will be awesome :-). - Hibernate OGM static module is included. WDYM by "static module"? The Hibernate OGM Core module?

How would people add the OGM backend module for the NoSQL store of their choice? I suppose you don't mean to add all the backends we have to WF by default (as this would increase size quite a bit), so would people still use the module ZIP we provide?

- need to align with OGM dependencies (e.g. Hibernate ORM + other dependencies). Note we aim at the ORM version part of WF at a given time. But there are times where we need a newer ORM version for a new OGM release (when using new SPIs not part in the ORM version coming with the currently released WF), so there should be a way to achieve that.

- as mentioned above, OGM already has some connection setup code, which might be good to share for WildFly + standalone NoSQL use. I'm not sure how re-usable this is. It's geared towards OGM's needs, I feel having a separate SPI dealing just with connections would be more useful.

- once WildFly has a common NoSQLSource (not a DataSource) that OGM can use, OGM will be enhanced to use it. +1 5. How best for the WildFly NoSQL subsystem to be optional? - Is it enough to not run the wildfly/testsuite/nosql tests by default? - Or do we need to start a separate https://github.com/wildfly/nosql project for the NoSQL subsystems? Would there be one OGM sub-system? Or one per NoSQL store?

And how would people add them (see above)? As said before in this thread, there should be a way to update modules of specific stores to get the latest and greatest.

6. transaction enlistment 7. compensating transactions 8. runtime application monitoring 9. How soon can we make an evaluation distribution available for use on OpenStack/OpenShift? - Would be great if we could do some load testing with all NoSQL components. - Would be great if we could enable others to also test. 10. Are there any problems with our WildFly NoSQL subsystem injecting MongoDatabase connections via: @Resource(lookup = "java:jboss/mongodb/test") MongoDatabase db; - No @Resource support expected for standalone Java, TBD is whether a runtime library can be used. - Any problems expected on other EE application servers if this approach becomes popular? 11. WIP topic branch is at https://github.com/scottmarlow/wildfly/tree/nosql-dev9. Note that every once in a while, commits are squashed and pushed to nosql-devN+1. Any pointers where to start looking to see what's working already?

12. Add proper unit tests - multi-threaded NoSQL access to show that works at all. - use NoSQL from different EE components (e.g. JAX-RS). - other use cases that represent how NoSQL could be used from WildFly. Feedback/help is welcome! Thanks, Scott _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 11 mai 2016, at 16:02, Scott Marlow <smarlow(a)redhat.com&gt; wrote: >> Hibernate OGM should still be usable without WF; So maybe there should >> be a separate project/repo which defines an SPI to obtain/manage >> connections and implementations for different NoSQL stores? > > Excellent suggestion, perhaps the SPI could be under > https://github.com/jboss, which is a common area for sharing. Possible > locations for creating the per NoSQL store implementations could be > https://github.com/jboss or https://github.com/hibernate or > https://github.com/wildfly. I'm starting to think that this might be way overkill. If we are creating a sub project just to share between 20 and 50 lines of code per provider and the overhead code to abstract property configuration to plus OGM and WF ones, we are losing more than gaining. Thoughts ? _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 11 mai 2016, at 16:02, Scott Marlow <smarlow(a)redhat.com&gt; wrote: >> Hibernate OGM should still be usable without WF; So maybe there should >> be a separate project/repo which defines an SPI to obtain/manage >> connections and implementations for different NoSQL stores? > > Excellent suggestion, perhaps the SPI could be under > https://github.com/jboss, which is a common area for sharing. Possible > locations for creating the per NoSQL store implementations could be > https://github.com/jboss or https://github.com/hibernate or > https://github.com/wildfly. I'm starting to think that this might be way overkill. If we are creating a sub project just to share between 20 and 50 lines of code per provider and the overhead code to abstract property configuration to plus OGM and WF ones, we are losing more than gaining. Thoughts ?

On 12 May 2016 at 12:24, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > > > On 11 mai 2016, at 16:02, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > >>> Hibernate OGM should still be usable without WF; So maybe there should >>> be a separate project/repo which defines an SPI to obtain/manage >>> connections and implementations for different NoSQL stores? >> >> Excellent suggestion, perhaps the SPI could be under >> https://github.com/jboss, which is a common area for sharing. Possible >> locations for creating the per NoSQL store implementations could be >> https://github.com/jboss or https://github.com/hibernate or >> https://github.com/wildfly. > > I'm starting to think that this might be way overkill. If we are creating a sub project just to share between 20 and 50 lines of code per provider and the overhead code to abstract property configuration to plus OGM and WF ones, we are losing more than gaining. > > Thoughts ? I agree it's overkill, and have an alternative proposal: Hibernate OGM should define an interface which is appropriate for its own consumption; the Wildfly NoSQL subssystem can have its own interface so to not depend on OGM, but they would be somewhat similar for each given NoSQL technology we intend to support in this way.

Then JipiJapa can inject an adaptor into the OGM boostrap phase, delegating from one to the other. So only the OGM specific JipiJapa module would need to depend on both interfaces. If this dependency is not desirable either, then I think we can live with a non-typesafe generic provider of things.

Thanks, Sanne

On 12 May 2016 at 12:24, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > > > On 11 mai 2016, at 16:02, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > >>> Hibernate OGM should still be usable without WF; So maybe there should >>> be a separate project/repo which defines an SPI to obtain/manage >>> connections and implementations for different NoSQL stores? >> >> Excellent suggestion, perhaps the SPI could be under >> https://github.com/jboss, which is a common area for sharing. Possible >> locations for creating the per NoSQL store implementations could be >> https://github.com/jboss or https://github.com/hibernate or >> https://github.com/wildfly. > > I'm starting to think that this might be way overkill. If we are creating a sub project just to share between 20 and 50 lines of code per provider and the overhead code to abstract property configuration to plus OGM and WF ones, we are losing more than gaining. > > Thoughts ? I agree it's overkill, and have an alternative proposal: Hibernate OGM should define an interface which is appropriate for its own consumption; the Wildfly NoSQL subssystem can have its own interface so to not depend on OGM, but they would be somewhat similar for each given NoSQL technology we intend to support in this way. Then JipiJapa can inject an adaptor into the OGM boostrap phase, delegating from one to the other. So only the OGM specific JipiJapa module would need to depend on both interfaces. If this dependency is not desirable either, then I think we can live with a non-typesafe generic provider of things.

Hi, Below is an update on the WildFly NoSQL integration project. The goal is for deployed applications to have access to NoSQL databases (via Hibernate OGM or native APIs). Items 1-4, should be finished in our first pass, with as much of the others items as we can do as well. 1. connection management will deal with obtaining NoSQL connections for application use. - borrow/share Hibernate OGM connection configuration setup code - authentication integration - support transport level security 2. CDI programming simplifications will make it easy to inject NoSQL data into your application classes. - https://github.com/antoinesd/javaee-nosql is initial idea 3. You will easily get a native NoSQL connection from the specified NoSQL profile and use the native NOSQL (Cassandra/MongoDB/other) API in your application. 4. You will also be able to easily use Hibernate OGM with the defined NoSQL profiles (exactly how is TBD but will be awesome :-). - Hibernate OGM static module is included. - need to align with OGM dependencies (e.g. Hibernate ORM + other dependencies). - as mentioned above, OGM already has some connection setup code, which might be good to share for WildFly + standalone NoSQL use. - once WildFly has a common NoSQLSource (not a DataSource) that OGM can use, OGM will be enhanced to use it. 5. How best for the WildFly NoSQL subsystem to be optional? - Is it enough to not run the wildfly/testsuite/nosql tests by default? - Or do we need to start a separate https://github.com/wildfly/nosql project for the NoSQL subsystems? 6. transaction enlistment 7. compensating transactions 8. runtime application monitoring 9. How soon can we make an evaluation distribution available for use on OpenStack/OpenShift? - Would be great if we could do some load testing with all NoSQL components. - Would be great if we could enable others to also test. 10. Are there any problems with our WildFly NoSQL subsystem injecting MongoDatabase connections via: @Resource(lookup = "java:jboss/mongodb/test") MongoDatabase db; - No @Resource support expected for standalone Java, TBD is whether a runtime library can be used. - Any problems expected on other EE application servers if this approach becomes popular? 11. WIP topic branch is at https://github.com/scottmarlow/wildfly/tree/nosql-dev9. Note that every once in a while, commits are squashed and pushed to nosql-devN+1. 12. Add proper unit tests - multi-threaded NoSQL access to show that works at all. - use NoSQL from different EE components (e.g. JAX-RS). - other use cases that represent how NoSQL could be used from WildFly. Feedback/help is welcome! Thanks, Scott _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 10 May 2016, at 16:45, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > That reminds me that we wanted to make the connection to JDG as simple > as MongoDB and the like. (i.e. a URL scheme more or less). > I'm talking about JDG remote here even though local would be a nice to > have. > > How hard would that be? I think that org.wildfly.clustering.dispatcher.CommandDispatcher is for invoking nodes on the WildFly cluster but I'm not sure of the API for invoking JDG remote and whether that is planned to be part of WildFly already, as part of our clustering effort. Could/should JDG access fall into NoSQL integration?