Once again, thanks very much for the input and sorry for the late response....
Here's where I am at... I was pushing forward with just using the aries pooling bundle, however it seemed to *not* do what I would normally expect with connections after a query/exception problem. It would leave them in the pool and allow for their reuse by subsequent queries. This would then lead to 'Connection already closed' or 'communication link failure' type messages in subsequent JPA operations unrelated to the previous problem. With this, I tried once again to work with the PAX dbcp2 bundle and ran into the same problems I had before with the tranql classes calling methods on the wrapped connection that DBCP2 did not like. I went so far as to comment some of the parts of the tranql ManagedJDBCConnection class to prevent it calling down into the DBCP2 connection. When this happened, my queries/transactions would continue on but then fail during another method call (like #commit) where the DBCP2 connection would throw an exception complaining about not being able to perform certain operations when participating in a managed transaction. So, it seemed to me like my DBCP2 connections were already XA aware/enlisted (or whatever you call it) and that the higher-level stuff in aries-jdbc/tranql was incompatible with them. So, here is where it gets really interesting... thinking about this problem I wondered if maybe I didn't even need the aries-wrapped datasources. So, I changed my eclipselink/jpa JNDI lookups to be !(aries.managed=true), to hopefully force eclipselink to use the DBCP2 XA datasource services directly. Well, voila... this seems to not only work, but still provide the xa/jta management as well. To test this I created a conflicting entity row in only one of my three eclipselink partitions or 'nodes'. Attempting to persist the corresponding entity in osgi via my jpa classes failed with the expected exception indicating a conflicting row *and* inspecting the database nodes showed that the only node with the row was the original node where it was manually inserted for the test. So, I'm assuming this is an indicator that the XA stuff ran as expected and prevented the insert from propagating to other nodes because the coordinated transaction was rolled back. So, my question is - does this setup make sense? To have the aries transaction manager/bundles in-place but not actually use the aries-managed datasources? Perhaps there are facilities in the pax dbcp2 pool bundle that does the auto-enlistment already? Perhaps I have no idea what I am talking about? Any guidance is greatly appreciated. Thanks. -matt -----Original Message----- From: Christian Schneider [mailto:[email protected]] On Behalf Of Christian Schneider Sent: Wednesday, September 23, 2015 1:53 AM To: [email protected] Subject: Re: Bundle set recommendations for JPA+JTA+Eclipselink Partitioning? Not sure why you hit the problem with dbcp2 and eclipselink. I have some itests running with eclipselink and they showed no problems. Will look into what versions I used exactly. I am not very familiar with the aries pooling but it should work fine. Christian Am 23.09.2015 um 02:48 schrieb [email protected]: > Ok, thanks so much for the suggestions. > > It is interesting to me that this isn't something someone else has seen > since I feel like I am using the pax-jdbc and aries bundles in a > straightforward way. > > Do you have a recommendation of using the aries pool bundle vs. the dbcp2 > one? I'm not set on either one, I just need it to work, have some > tweakability and perform well enough. I had been leaning towards dbcp2 since > it seems like a reasonable, actively developed pool implementation that I > have used elsewhere, but since it doesn't currently work for me I'm fine > using aries if it works and performs. > > It seems to me that the aries pooling basically delegates back to the > Geronimo classes, which I would suspect are a decent pool implementation > themselves having originated as part of that project. But I have no > experience with them, so my confidence is low. > > Obviously, I'll do some performance tests when all this comes together more, > but recommended best practices or known working bundle combinations are > always a good starting point. I'm still looking through your earlier > references and all the itest stuff to try to piece together a logical bundle > set, but it's slow for me as I am not very familiar with PaxExam. > > Thanks, > -matt > > -----Original Message----- > From: Christian Schneider [mailto:[email protected]] On Behalf Of > Christian Schneider > Sent: Tuesday, September 22, 2015 4:04 PM > To: [email protected] > Subject: Re: Bundle set recommendations for JPA+JTA+Eclipselink > Partitioning? > > Honestly I have no idea why tranql sets the autocommit. I would not > expect that it needs to be tweaked. > > I can imagine that dbcp2 does not allow to change autocommit for XA > transactions as the commit should > only be done when the XA transaction commits. Not sure about this either > though. > > I propose you ask this on the apache commons list or open an issue for > dbcp2. It definitely seems to be an issue that > can also happen when just configuring dbcp2 manually and then use tranql > on it. > > Christian > > Am 22.09.2015 um 20:19 schrieb [email protected]: >> [1] is a snippet from the stacktrace I get when using pax-jdbc-pool-dbcp2 >> instead of -aries. As you can see, >> ManagedJDBCConnection#localTransactionStart appears to call setAutoCommit > on >> the connection class, which the DBCP2 impl short circuits at [2]. >> >> This same exact environment seems to run fine with the -aries pool bundle. > I >> am running this with a customized transactions-jdbc bundle checked-out > from >> SVN. But, the only change I made was the pull in all the tranql source to >> fix issues with the two-arg form of getConnection in some of those > classes. >> Aside from that it's unchanged and works fine with the -aries pooling >> bundle. >> >> Any suggestions are greatly appreciated. >> >> [1] >> Caused by: javax.resource.spi.LocalTransactionException: Unable to disable >> autoCommit >> at >> > org.tranql.connector.jdbc.ManagedJDBCConnection.localTransactionStart(Manage >> dJDBCConnection.java:83) >> ~[org.apache.aries.transaction.jdbc-2.1.2-SNAPSHOT.jar:2.1.2-SNAPSHOT] >> at >> > org.tranql.connector.AbstractManagedConnection$LocalTransactionImpl.begin(Ab >> stractManagedConnection.java:195) >> ~[org.apache.aries.transaction.jdbc-2.1.2-SNAPSHOT.jar:2.1.2-SNAPSHOT] >> at >> > org.apache.geronimo.connector.outbound.LocalXAResource.start(LocalXAResource >> .java:107) ~[geronimo-connector-3.1.3.jar:3.1.3] >> ... 76 common frames omitted >> Caused by: java.sql.SQLException: Auto-commit can not be set while > enrolled >> in a transaction >> at >> > org.apache.commons.dbcp2.managed.ManagedConnection.setAutoCommit(ManagedConn >> ection.java:223) ~[na:na] >> at >> > org.tranql.connector.jdbc.ManagedJDBCConnection.localTransactionStart(Manage >> dJDBCConnection.java:81) >> ~[org.apache.aries.transaction.jdbc-2.1.2-SNAPSHOT.jar:2.1.2-SNAPSHOT] >> ... 78 common frames omitted >> >> [2] >> public void setAutoCommit(boolean autoCommit) throws SQLException { >> if (transactionContext != null) { >> >> throw new SQLException("Auto-commit can not be set while enrolled in a > trans >> action"); >> } >> super.setAutoCommit(autoCommit); >> } >> >> >> -----Original Message----- >> From: [email protected] > [mailto:[email protected]] >> Sent: Tuesday, September 22, 2015 11:14 AM >> To: [email protected] >> Subject: RE: Bundle set recommendations for JPA+JTA+Eclipselink >> Partitioning? >> >> Thanks very much for the references, I will definitely be looking over > them. >> I was hoping the dbcp2 bundle would allow for the same XA capability, as I >> would prefer dbcp2 pooling since it seems fairly analogous to my current >> pooling - bonecp. However, I did some testing with dbcp2 and got > exceptions >> during runtime when code from base datasource wrappers (from tranql maybe) >> was attempting to set the auto-commit flag and the DBCP datasource wrapper >> class was throwing an exception about setting auto-commit. I can't > remember >> exactly the code flow but I'll try to test this again and see about > getting >> a stacktrace. Does any of this sound familiar? Should I be able to simply >> replace pax-jdbc-pool-aries with pax-jdbc-pool-dbcp2 in my runtime? Maybe > it >> was something in my jndi references not getting the aries-managed > datasource >> services. >> >> As for the blueprint/DS question, I will be largely using DS to inject >> app-specific API that gives my code access to the > JpaTemplate/EntityManager >> classes. I hope to move toward blueprint, but that will be another effort. >> >> Thanks again, >> -matt >> >> -----Original Message----- >> From: Christian Schneider [mailto:[email protected]] On Behalf Of >> Christian Schneider >> Sent: Tuesday, September 22, 2015 10:24 AM >> To: [email protected] >> Subject: Re: Bundle set recommendations for JPA+JTA+Eclipselink >> Partitioning? >> >> Hi Matthew, >> >> pax-jdbc-pool-dbcp2 as well as pax-jdbc-pool-aries should both be able >> to provide XA enlisting poolable DataSources. >> Aries JPA and Transaction actually use the above in their integration >> tests. So they should work together nicely. >> >> I got two tutorials that both use XA transactions with Aries: >> > http://liquid-reality.de/display/liquid/2015/06/30/Apache+Karaf+Tutorial+par >> t+10+-+Declarative+services >> > http://liquid-reality.de/display/liquid/2015/03/05/Apache+Karaf+Tutorial+Par >> t+9+-+Annotation+based+blueprint+and+JPA >> >> Btw. Do you plan to use blueprint or DS? >> >> Christian >> >> On 03.09.2015 22:51, [email protected] wrote: >>> Ok, maybe I can answer my own questions here, but if I could get some >>> confirmation that would be great. I seem to have a working system running >>> with ops4j-pax-jdbc-pool-aries rather than dbcp2. >>> >>> Digging into the code in org.apache.aries.transaction.jdbc it looks like >>> RecoverableDataSource is the wrapper for my XADataSources and it does >> indeed >>> appear to support passing of pooling options onto > ConnectionManagerFactory >>> which itself appears to use the pooling capabilities that come from the >>> Geronimo bundles. Does all this sound correct so far? >>> >>> So, it's not dbcp2, but it's pooling nonetheless and I can adjust >>> preferences by passing the appropriate bean options to my pax-jdbc > service >>> with the 'pool.' prefix which will in-turn send those on to the >>> RecoverableDataSource instance. Sound ok still? >>> >>> And finally, my eclipselink JTA datasource JNDI lookups are formatted > with >>> filters for the 'aries.managed' property [1] to ensure that I get the >> aries >>> auto-enlisting DataSources. >>> >>> So far, this is running my existing code ok with only two changes I had > to >>> make: >>> >>> 1. Fixed ARIES-1171, but actually in the Tranql code as I was getting >>> connection errors and didn't see a logical place to fix it from an aries >>> class (using latest aries-transaction-jdbc from SVN). This required >> bringing >>> all the tranql source into my aries bundle and just removing the external >>> dependency. I didn't like doing that, but since that code hasn't changed >> in >>> a while and I'm still prototyping all this it was the path of least >>> resistance. >>> >>> 2. Changed RecoverableDataSource to not use empty strings by default for >>> username and password. Which seemed to be similar/related to the above > and >> I >>> posted as ARIES-1376. >>> >>> Thoughts and criticisms welcome. Thanks! >>> >>> [1] >>> > osgi:service/javax.sql.DataSource/(&(osgi.jndi.service.name=my-app-node1)(ar >>> ies.managed=true)) >>> >>> -----Original Message----- >>> From: [email protected] >> [mailto:[email protected]] >>> Sent: Thursday, September 03, 2015 10:58 AM >>> To: [email protected] >>> Subject: Bundle set recommendations for JPA+JTA+Eclipselink Partitioning? >>> >>> I am in the process of refactoring an existing JPA/Eclipselink-based >>> application to introduce Eclipselink's partitioning support for database >>> sharding. My current application runs quite well with pooled jdbc >>> connections via boncep. >>> >>> However, with the sharded model there will be a number of entity types >> that >>> are Replicated to all shards and, as such, eclipselink will be doing >> writes >>> that span multiple jdbc connections. Per the eclipselink recommendations >> for >>> paritioning I would like to introduce JTA in order to enforce integrity >>> across commits that hit multiple partitions. >>> >>> It seems like the ops4j-pax-jdbc bundles are designed to support XA/JTA >> and >>> it seems like there is a lot of XA support in the various aries bundles >>> (aries.transaction. and aries.jpa.). However, I'm not sure of what >>> combination of these bundles+configuration will provide what I am after. >>> Since many of these bundles seem to be designed/documented around general >>> JTA usage - like performing a transaction that spans JMS and JDBC - I'm >> not >>> confident if that model works with my particular use case. >>> >>> To further add to this, I would like for my JDBC connections to be pooled >>> for performance. ops4j-pax-jdbc-pool-dbcp2 seems like a logical choice, >> but >>> again I'm not sure if it will play nicely with the transaction management >>> features from aries. >>> >>> I think I have a working model of this, but I'm rather new to XA/JTA >>> especially from OSGi so I want to make sure I'm getting this correct. So, >> I >>> guess my questions are: >>> >>> 1. Can ops4j-pax-jdbc-pool and it's dbcp2 sibling work with >>> aries-jpa/transaction to pool and auto-enlist XADataSources? >>> >>> 2. If not, will ops4j-pax-jdbc-pool-aries work? And if so, can its > pooling >>> semantics be configured? E.g. minIdle, maxIdle, etc. >>> >>> 3. If neither of the above works, is there a recommended set of bundles > to >>> accomplish pooled XADataSources with eclipselink+JTA? >>> >>> >>> Thanks, >>> >>> >>> Matthew Pitts >>> >>> Developer >>> Security Solutions Design & Automation >>> >>> Wells Fargo Bank | Tel 336.608.3332 | Cell 336.202.3913 | Kernersville, > NC >> | >>> MAC D9693-010 >>> [email protected] >>> >>>
smime.p7s
Description: S/MIME cryptographic signature
