openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <mprud...@apache.org>
Subject Re: Possible problem with ddl with only a jta-datasource and sequences
Date Tue, 24 Apr 2007 18:38:08 GMT
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
>


Mime
View raw message