openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@bea.com>
Subject RE: Possible problem with ddl with only a jta-datasource and sequences
Date Wed, 25 Apr 2007 18:41:44 GMT
> 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.

That's one approach for out-of-band work. But, there are other ways to
do such work also, without requiring multiple datasources. For example,
suspending the current tx, starting a new one, doing the work,
committing, and resuming the old one is a workable solution, if you have
access to the tx.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc.
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it. 

> -----Original Message-----
> From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM] 
> Sent: Wednesday, April 25, 2007 10:05 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: Possible problem with ddl with only a 
> jta-datasource and sequences
> 
> 
> 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:Craig.Russell@sun.com P.S. A good JDO? O, Gasp!
> 
> 

Notice:  This email message, together with any attachments, may contain information  of  BEA
Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,
 copyrighted  and/or legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete it.

Mime
View raw message