I think the important question is: *Who* determines whether to use the <jta-datasource> or the <non-jta-datasource>?
The follow-up question would be: *What criteria* is being used to choose between them? /Bengt 2016-07-11 10:58 GMT+02:00 Bengt Rodehav <[email protected]>: > Edited the WIKI: > https://ops4j1.jira.com/wiki/display/PAXJDBC/Apache+Derby+Driver+Adapter > > About the auto-commit problem. > > I found this: > https://mail-archives.apache.org/mod_mbox/openjpa-users/201002.mbox/%[email protected]%3E > > > It refers to the following JIRA: > https://issues.apache.org/jira/browse/DERBY-1236 > > I can't see how this could be a JDBC problem though. I would suspect > OpenJPA. Isn't it OpenJPA who knows about the <jta-datasource> and the > <non-jta-datasource> or is it JPA Blueprint? > > There is also a difference in the way I published the datasource with > Blueprint and the way it is being done in pax-jdbc. With Blueprint I > published both a DataSource and an XADataSource. pax-jdbc is only > publishing a DataSource but somehow still supports XA (I don't really know > how this works). > > There is a risk that someone (OpenJPA, JPA Blueprint, ...) is checking if > it is dealing with a DataSource or an XADataSource. If the first then auto > commit should be OK, if the latter not and it may then try the > <non-jta-datasource> instead. Since we are only publishing a DataSource > (via pax-jdbc) it could signal to a client that auto commit is OK since > this is not an XADataSource. Do you agree? > > /Bengt > > > 2016-07-11 10:37 GMT+02:00 Christian Schneider <[email protected]>: > >> You config looks good. I think it would be great to update the docs. Can >> you edit this yourself in the pax-jdbc wiki? >> If you do not have wiki access you can ask for it on the ops4j mailing >> list. >> >> The error you get: Auto-commit can not be set while enrolled in a >> transaction" might be an issue in dbcp2. I thought it would be solved >> already. >> You can try to report it at openjpa and dbcp2. If you do not use the >> newest pax-jdbc version then you could also try that. >> >> Unfortunately I was not able to find the issue at pax-jdbc or dbcp2. >> >> Christian >> >> >> >> >> >> On 11.07.2016 10:00, Bengt Rodehav wrote: >> >> Thanks Christian, >> >> It seemed the reason why the pax-jdbc datasource wasn't picked up by JPA >> Blueprint was that I had given it the wrong name... >> >> I had forgotten the "jdbc/" prefix that I use in my persistence.xml. It >> is now picked up as it should. >> >> There is, however, an error in the documentation in the link you gave me. >> It says: >> >> --- >> Method Arguments >> >> The argument passed to createDataSource(), >> createConnectionPoolDataSource(), createXADataSource() supports the >> following properties: >> >> - DataSourceFactory.JDBC_DATABASE_NAME (mandatory) >> - DataSourceFactory.JDBC_USER >> - DataSourceFactory.JDBC_PASSWORD >> >> *An SQLException is thrown if any other properties are set* or if a >> mandatory property is missing. >> >> -- >> >> >> But I need to pass properties directly to the jdbc driver. In my case >> "createDatabase=create" so that the database is created if it doesn't >> already exists. I therefore set this property in my org.ops4j.datasource >> configuration as follows: >> >> osgi.jdbc.driver.name=derby-pool-xa >> databaseName=historyDB >> dataSourceName=jdbc/filetransferhistory >> createDatabase=create >> >> The "createDatabase" property is passed to the driver so that the >> database is created. So, it is OK to pass other properties as well - they >> get passed along. >> >> However, I do still have a problem getting the Derby database to be >> created. When trying to create a new database I get: >> >> >> Caused by: java.sql.SQLException: Auto-commit can not be set while >> enrolled in a transaction >> at >> org.apache.commons.dbcp2.managed.ManagedConnection.setAutoCommit(ManagedConnection.java:223) >> at >> org.apache.openjpa.lib.jdbc.DelegatingConnection.setAutoCommit(DelegatingConnection.java:167) >> at >> org.apache.openjpa.lib.jdbc.DelegatingConnection.setAutoCommit(DelegatingConnection.java:167) >> at >> org.apache.openjpa.lib.jdbc.ConfiguringConnectionDecorator$ConfiguringConnection.setAutoCommit(ConfiguringConnectionDecorator.java:116) >> at >> org.apache.openjpa.jdbc.schema.SchemaTool.executeSQL(SchemaTool.java:1297) >> at >> org.apache.openjpa.jdbc.schema.SchemaTool.createTable(SchemaTool.java:1017) >> at >> org.apache.openjpa.jdbc.schema.SchemaTool.buildSchema(SchemaTool.java:573) >> at >> org.apache.openjpa.jdbc.schema.SchemaTool.add(SchemaTool.java:481) >> at >> org.apache.openjpa.jdbc.schema.SchemaTool.add(SchemaTool.java:368) >> at >> org.apache.openjpa.jdbc.schema.SchemaTool.run(SchemaTool.java:343) >> at >> org.apache.openjpa.jdbc.meta.MappingTool.record(MappingTool.java:507) >> ... 46 more >> >> It works if I instead use "derby" or "derby-pool" DataSourceFactory. I >> tried to provide a <non-jta-datasource> for this purpose but it is never >> being used. I thought this was the reason why a <non-jta-datasource> should >> be provided. Not sure whether this is a problem with JPA blueprint or if >> its a problem in OpenJPA. Maybe I should ask on the OpenJPA mailing list? >> >> /Bengt >> >> >> >> -- >> Christian Schneiderhttp://www.liquid-reality.de >> >> Open Source Architecthttp://www.talend.com >> >> >
