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
