openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <michael.d.d...@gmail.com>
Subject Re: Possible problem with ddl with only a jta-datasource and sequences
Date Tue, 24 Apr 2007 19:23:02 GMT
I ran into similar problems with WebSphere - which doesn't allow the
transaction to be suspended. Of course in WebSphere you need to use
Connection2xxx properties until the non-jta-datasource support is available.


One other solution is to execute a query before you do your first unit of
work - running the query will trigger SynchronizeMappings to go ahead and
create the tables. It's a bit ugly, but might be nicer than spinning a
thread.

-Mike

On 4/24/07, Marc Prud'hommeaux <mprudhom@apache.org> 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.
>
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message