openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Possible problem with ddl with only a jta-datasource and sequences
Date Wed, 25 Apr 2007 17:05:25 GMT

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.

> 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  
>> 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
408 276-5638
P.S. A good JDO? O, Gasp!

View raw message