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 <[EMAIL PROTECTED]> 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
>
