David-
Does this seem like a reasonable explanation?
That sounds right to me.
Note that if we ever update OpenJPA to depend solely on the
TransactionSynchronizationRegistry, then we won't be able to do
things like suspending the transactions and resuming it later with
the jta-datasource.
On Apr 24, 2007, at 10:52 AM, David Jencks wrote:
Using derby, jta transactions (in geronimo), a table sequence,
autocreation of tables, and only a jta-datasource, I get errors
complaining that the sequence table doesn't exist.
Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: Table/
View 'OPENJPASEQ' does not exist. {SELECT SEQUENCE_VALUE FROM
OPENJPASEQ WHERE ID = ? FOR UPDATE WITH RR} [code=20000, state=42X05]
If I supply a non-jta-datasource everything works fine.
My current theory about why this is happening is that the ddl to
create all the tables is executed in a connection from the jta-
datasource that's enrolled in a jta transaction. Then we go to get
an id from the sequence, the jta transaction is suspended, and a
new tx is started, in which the ddl is not visible since the jta tx
wasn't committed. (apparently ddl in derby is transactional)
Does this seem like a reasonable explanation?
I'm going to look for a way to run the ddl inside a separate
transaction that can be committed, the same as how sequences work
without a non-jta-datasource. One way to do this would be to
package the work up in a Runnable and execute it in an appropriate
transactional environment. It might be easier to understand if the
sequence code had a similar implementation.
thanks
david jencks