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.

david jencks

Reply via email to