Re: Possible problem with ddl with only a jta-datasource and sequences

[Craig L Russell]

Hi Partick,

On Apr 25, 2007, at 11:41 AM, Patrick Linskey wrote:

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

suspending the current tx, starting a new one, doing the work,

access to the tx.

do such work also, without requiring multiple datasources. For example, committing, and resuming the old one is a workable solution, if you have

Craig

My comment was that the two-datasource approach works for all configurations that I know of, and doesn't depend on the existence of mutliple non-standardized interfaces by which the transaction service providers have granted grudging access to their transaction control mechanism. There was agreement with TSR on the basic functionality that all transaction service providers would support. Some vendors pushed back when we tried to expand the functionality. If "everyone" has extra functionality why is it so hard to come to a common set of features? There's no intrinsic value in one app server giving access via Proprietary Interface 1 and another app server giving the same access via Proprietary Interface 2. What we were able to get with TSR interface was agreement as to how to deal with transaction-enlisted connections. Perhaps we need to go back (Umbrella JSR for Java EE 6) and make a bigger fuss over the additional needed functionality.

-Patrick

--
Patrick Linskey
BEA Systems, Inc.

by email and then delete it.

______________________________________________________________________ _ 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

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
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:[EMAIL PROTECTED] 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.

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature