Hello; I had a few questions about the proper usage of the Narayana transactional JDBC driver.
Suppose I have Narayana JTA running (as a JTA-compliant transaction manager). Suppose further I have a JPA implementation running (EclipseLink, say) that "knows" that a JTA transaction manager is in the picture, such that its
EntityManagers are under JTA control. Now suppose that I have a non-XA
DataSource I wish to use to back JPA's
<jta-data-source>. I am not, as a user, interested in distributed transactions, in other words, but I do want to take advantage of injected
EntityManagers, which are required by specification to be JTA controlled. This is a very common case.
It is my understanding this is one of the cases that the transactional JDBC driver exists to solve in some fashion. Is that correct?
If I understand right, the Narayana transactional JDBC driver wraps an
java.sql.Driver clothing. Is that right?
If I wanted to use the HikariCP connection pool, which doesn't support XA itself, but is otherwise an excellent connection pool, I could tell it to pool Narayana JDBC driver URLs. I would also need to tell the Narayana transactional driver not to do any pooling of its own. Is that correct? So Hikari would pool Narayana JDBC driver URLs, which, indirectly, would effectively route to
XADataSources. Is that right?
One of the properties that I would supply in such a case would be a means of acquiring the
XADataSource that the Narayana JDBC driver wraps. I would (for my purposes) set the
dynamicClass property (if I remember right). Is that right?
If I'm right so far, then things look like this:
EclipseLink--uses-->DataSource.getConnection()-->supplied by-->Hikari--pools-->Narayana driver URLs--wraps-->XADataSource-->supplies XAConnection
Is that right?
Then magic happens, and even with the default auto commit settings in play two
INSERT statements would get rolled back when the JTA transaction rolls back. And it is the Narayana transactional driver that somehow makes this happen (that's sort of the part I'm missing).
Now, as it happens, I don't actually care about XA. I'm only ever going to use a connection to a single database (let's say). But it appears to me that the data source supplied to JPA via
<jta-data-source> must be XA-capable (even if it wraps a non-XA capable data source under the covers). Otherwise in the case of transaction rollbacks the various SQL statements that might have gone to the database could be visible after the rollback (there are many examples on the web of people being bitten in this way). Does the Narayana driver somehow solve this problem as well? Does it allow a non-XA
DataSource to somehow "play nice" with the JTA controller, or must I always supply an
XADataSource to the Narayana transactional driver?