Take a look at: http://openjpa.apache.org/builds/1.2.3/apache-openjpa/docs/ref_guide_dbsetup_thirdparty.html
Look under "2.1 Managed and XA DataSources": "When using a managed DataSource, you should also configure a second unmanaged DataSource that OpenJPA can use to perform tasks that are independent of the global transaction. The most common of these tasks is updating the sequence table OpenJPA uses to generate unique primary key values for your datastore identity objects. Configure the second DataSource using the non-jta-data-source persistence.xml element, or OpenJPA's various "2" connection properties, such asopenjpa.ConnectionFactory2Name or openjpa.Connection2DriverName." /Bengt 2016-07-11 11:33 GMT+02:00 Bengt Rodehav <[email protected]>: > 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 >> >> >
