On Apr 24, 2007, at 11:38 AM, Marc Prud'hommeaux wrote:
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.
That's why we have two datasources for an EMF. One is the transactional datasource that gives you connections automatically enlisted in your transactional EM; the other gives you connections that are never enlisted and can be used for nontransactional queries, nontransactional sequences etc. The TSR is only of use for the enlisted datasource/connection.
Craig
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
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
