So, in conclusion, either OpenJPA has changed the logic for choosing datasource or OpenJPA was relying on checking the type of the data source (DataSource or XADataSource) to determine what data source to choose. I would guess the latter.
But, by instead specifying, the "openjpa.ConnectionFactory2Name" property I can short circuit this and get it to work. Thanks a lot for your invaluable help Christian. /Bengt 2016-07-11 11:46 GMT+02:00 Bengt Rodehav <[email protected]>: > It seems to be OpenJPA who makes the choice. I read further in the section > in OpenJPA documentation I mentioned. I now added the OpenJPA property: > > <property name="openjpa.ConnectionFactory2Name" > value="osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/filetransferhistorynojta)" > /> > > It now works, the database is created properly. Somehow I would like to > check that JTA is used for the other operations though. > > /Bengt > > 2016-07-11 11:38 GMT+02:00 Christian Schneider <[email protected]>: > >> On 11.07.2016 11:33, Bengt Rodehav wrote: >> >>> So the spec doesn't really allow for both of them to be used... >>> >>> Maybe, before, a JTA transaction wasn't created for the "synchronize >>> mappings" and therefore the <non-jta-datasource> was used. Now a JTA >>> transaction is being created. Not sure if this was changed now that I >>> upgraded to newer Aries versions... >>> >> Can you try to just switch the db to H2. I did all my tutorials on H2 >> lately. It would be interesting if the issue also happens there. If it >> happens there too then I think it is not a derby issue. >> I normally use hibernate though so if it is a openjpa issue then I maybe >> just did not see it because of that. As openjpa only supports jta 1.2 >> lately I did not have the chance to test openjpa a lot. >> >> >>> It is a bit of a problem of course. It was a convenient way to create >>> the database on first usage that now does not seem to work. The only way I >>> can think of is to use an alternative pax-jdbc configuration on startup >>> (that uses derby or derby-pool datasource) and then shut down the container >>> and replace it with the derby-pool-xa datasource. Really complicates our >>> installations procedures... >>> >>> BTW, how come it works if I use the derby-pool datasource? Does someone >>> (who) recognize that this datasource does not support JTA and therefore >>> uses a RESOURCE_LOCAL transaction instead? Who is the "someone"? >>> >> No idea. >> >> >>> /Bengt >>> >>> >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Open Source Architect >> http://www.talend.com >> >> >
