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...
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"? /Bengt 2016-07-11 11:25 GMT+02:00 Christian Schneider <[email protected]>: > I looked it up in the jpa spec (see below). So I think I interpreted this > correctly. > Christian > > 8.2.1.2 transaction-type > The transaction-type attribute is used to specify whether the entity > managers provided by the > entity manager factory for the persistence unit must be JTA entity > managers or resource-local entity > managers. The value of this element is JTA or RESOURCE_LOCAL. A > transaction-type of JTA > assumes that a JTA data source will be provided—either as specified by the > jta-data-source ele- > ment or provided by the container. In general, in Java EE environments, a > transaction-type of > RESOURCE_LOCAL assumes that a non-JTA datasource will be provided. In a > Java EE environment, if > this element is not specified, the default is JTA. In a Java SE > environment, if this element is not speci- > fied, the default is RESOURCE_LOCAL. > > On 11.07.2016 11:15, Bengt Rodehav wrote: > > Sorry missed your last mail... > > Still wonders when the <non-jta-datasource> would be used? > > /Bengt > > 2016-07-11 11:13 GMT+02:00 Christian Schneider <[email protected]>: > >> On 11.07.2016 10:58, Bengt Rodehav wrote: >> >> >> 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). >> >> This is something I read in the transaction specs. The user should always >> use a DataSource. XADataSource is just for internal use by the app server. >> The app server has the responsibility of wrapping the XADataSource in a >> DataSource and do the resource enlistment with the TransactionManager. >> >> Christian >> >> >> 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 >> >> -- >>> Christian Schneiderhttp://www.liquid-reality.de >>> >>> Open Source Architecthttp://www.talend.com >>> >>> >> >> >> -- >> Christian Schneiderhttp://www.liquid-reality.de >> >> Open Source Architecthttp://www.talend.com >> >> > > > -- > Christian Schneiderhttp://www.liquid-reality.de > > Open Source Architecthttp://www.talend.com > >
