So I learned today that your
persistence.xml may have both a
<jta-data-source> and a
<non-jta-data-source> specified alongside each other. I’m not sure why I thought these were mutually exclusive but I figured someone else probably had this misunderstanding as well.
(I also was reminded of the fact that JDBC does not support nested transactions in a slightly related tangent.)
I also learned that some JPA providers can take advantage of a double listing: your run-of-the-mill JTA environment (such as an EJB server) will use the
<jta-data-source> by default, but the other one might be used by your JPA provider. The JPA specification doesn’t really say anything about this; section 126.96.36.199 is about as close as it gets:
188.8.131.52 jta-data-source, non-jta-data-source
In Java EE environments, the
non-jta-data-sourceelements are used to specify the global JNDI name of the JTA and/or non-JTA data source to be used by the persistence provider. If neither is specified, the deployer must specify a JTA data source at deployment or a JTA data source must be provided by the container, and a JTA EntityManagerFactory will be created to correspond to it.
These elements name the data source in the local environment; the format of these names and the ability to specify the names are product specific.
In Java SE environments, these elements may be used or the data source information may be specified by other means—depending upon the requirements of the provider.
Specifically, EclipseLink can use your
<non-jta-data-source> element if you instruct it—for example—to use a separate connection for
@TableGenerator-based identity generation. Otherwise, your sequence table operations will be only as granular as the (potentially long, hairy) transactions that wrap them.
<non-jta-data-source> had better be pointing at the same data source in this case.
File this under “Huh”.