<div dir="ltr">Hi Scott,<div><br></div><div>Thanks for driving this initiative!</div><div><br></div><div>Some comments/questions inline.</div><div><br></div><div class="gmail_extra"><div class="gmail_quote">2016-05-04 20:16 GMT+02:00 Scott Marlow <span dir="ltr"><<a href="mailto:smarlow@redhat.com" target="_blank">smarlow@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Below is an update on the WildFly NoSQL integration project. The goal<br>
is for deployed applications to have access to NoSQL databases (via<br>
Hibernate OGM or native APIs). Items 1-4, should be finished in our<br>
first pass, with as much of the others items as we can do as well.<br>
<br>
1. connection management will deal with obtaining NoSQL connections for<br>
application use.<br>
<br>
- borrow/share Hibernate OGM connection configuration setup code<br>
- authentication integration<br>
- support transport level security<br></blockquote><div><br></div><div>Any ideas how this code sharing could look like?</div><div><br></div><div>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?</div><div><br></div><div>I think it'd be beneficial to define some sort of connection URL syntax which can be used in NoSQL datasource definitions:</div><div><br></div><div> nosql:mongodb://192.168.1.100:27017[,another-host:another-port]/some_db?customParam1=xyz&customParam2=abc&...<br></div><div><br></div><div>This common syntax might do for most cases, for others it might be needed to support specialized schemes handled by store-specific SPI implementations.</div><div><br></div><div>Regarding pooling, many NoSQL drivers do it in one way or another, so maybe leave that to drivers, at least in the first iteration?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
2. CDI programming simplifications will make it easy to inject NoSQL<br>
data into your application classes.<br>
<br>
- <a href="https://github.com/antoinesd/javaee-nosql" rel="noreferrer" target="_blank">https://github.com/antoinesd/javaee-nosql</a> is initial idea<br></blockquote><div><br></div><div>+1 Sounds nice. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
3. You will easily get a native NoSQL connection from the specified<br>
NoSQL profile and use the native NOSQL (Cassandra/MongoDB/other) API in<br>
your application.<br></blockquote><div><br></div><div>Would you take measures to e.g. prevent closing a connection in application code?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
4. You will also be able to easily use Hibernate OGM with the defined<br>
NoSQL profiles (exactly how is TBD but will be awesome :-).<br>
- Hibernate OGM static module is included.<br></blockquote><div><br></div><div>WDYM by "static module"? The Hibernate OGM Core module?</div><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
- need to align with OGM dependencies (e.g. Hibernate ORM + other<br>
dependencies).<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
- as mentioned above, OGM already has some connection setup code,<br>
which might be good to share for WildFly + standalone NoSQL use.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
- once WildFly has a common NoSQLSource (not a DataSource) that OGM<br>
can use, OGM will be enhanced to use it.<br></blockquote><div><br></div><div>+1</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
5. How best for the WildFly NoSQL subsystem to be optional?<br>
- Is it enough to not run the wildfly/testsuite/nosql tests by default?<br>
- Or do we need to start a separate <a href="https://github.com/wildfly/nosql" rel="noreferrer" target="_blank">https://github.com/wildfly/nosql</a><br>
project for the NoSQL subsystems?<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
6. transaction enlistment<br>
<br>
7. compensating transactions<br>
<br>
8. runtime application monitoring<br>
<br>
9. How soon can we make an evaluation distribution available for use on<br>
OpenStack/OpenShift?<br>
- Would be great if we could do some load testing with all NoSQL<br>
components.<br>
- Would be great if we could enable others to also test.<br>
<br>
10. Are there any problems with our WildFly NoSQL subsystem injecting<br>
MongoDatabase connections via:<br>
<br>
@Resource(lookup = "java:jboss/mongodb/test") MongoDatabase db;<br>
<br>
- No @Resource support expected for standalone Java, TBD is whether a<br>
runtime library can be used.<br>
- Any problems expected on other EE application servers if this<br>
approach becomes popular?<br>
<br>
11. WIP topic branch is at<br>
<a href="https://github.com/scottmarlow/wildfly/tree/nosql-dev9" rel="noreferrer" target="_blank">https://github.com/scottmarlow/wildfly/tree/nosql-dev9</a>. Note that every<br>
once in a while, commits are squashed and pushed to nosql-devN+1.<br></blockquote><div><br></div><div>Any pointers where to start looking to see what's working already? </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
12. Add proper unit tests<br>
- multi-threaded NoSQL access to show that works at all.<br>
- use NoSQL from different EE components (e.g. JAX-RS).<br>
- other use cases that represent how NoSQL could be used from WildFly.<br>
<br>
Feedback/help is welcome!<br>
<br>
Thanks,<br>
Scott<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</blockquote></div><br></div></div>