You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by David Jencks <da...@yahoo.com> on 2007/04/24 19:52:40 UTC
Possible problem with ddl with only a jta-datasource and sequences
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
Re: Possible problem with ddl with only a jta-datasource and sequences
Posted by Kevin Sutter <kw...@gmail.com>.
On 4/24/07, Patrick Linskey <pl...@bea.com> wrote:
>
> > Can you ask the websphere team to support a Callable also, so
> > we can easily return a value or throw an exception from the
> > task?
>
> Seems like for WAS's needs, just supporting Callable would be good
> enough, no?
Unfortunately, I am just the messenger in this case. The WebSphere
Transactions team has already designed and developed this Runnable solution
and has made it available via a FixPack. So, it's "cast in concrete"
now... :-)
Kevin
We need to use Runnable at the end of the day in ManagedRuntime, so that
> things compile on 1.4.
>
> -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: Dain Sundstrom [mailto:dain@iq80.com]
> > Sent: Tuesday, April 24, 2007 3:29 PM
> > 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 2:17 PM, Kevin Sutter wrote:
> >
> > > Patrick,
> > >
> > > On 4/24/07, Patrick Linskey <pl...@bea.com> wrote:
> > >>
> > >> > 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.
> > >>
> > >> We talked about this in a thread several months ago. I
> > think that the
> > >> conclusion was that it'd be neat to make our
> > ManagedRuntime interface
> > >> have a runInNewTransaction(Runnable) method, and to move things to
> > >> use that instead of doing tx logic directly inside the sequence
> > >> classes.
> > >> This would be an easy change; the lack of a concrete need (i.e., a
> > >> server that both denied transactional control and provided
> > a means to
> > >> execute a Runnable in a new tx) prevented us from changing things
> > >> around.
> > >
> > >
> > > A "concrete need" is surfacing with WebSphere. WebSphere does not
> > > allow for direct transactional control (ie. suspend/resume)
> > and it has
> > > recently provided the means to execute a Runnable in a new
> > Tx (via the
> > > "runUnderUOW"
> > > feature). Although WebSphere may be the exception to the
> > rule, we are
> > > planning on providing the mechanism so that OpenJPA can
> > play in this
> > > game.
> >
> > Kevan,
> >
> > Can you ask the websphere team to support a Callable also, so
> > we can easily return a value or throw an exception from the
> > task? It may also be important to runWithoutTx for databases
> > that don't support transactional DDL, but I suppose that
> > could be done with a new thread.
> >
> > -dain
> >
>
> 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.
>
RE: Possible problem with ddl with only a jta-datasource and sequences
Posted by Patrick Linskey <pl...@bea.com>.
> Can you ask the websphere team to support a Callable also, so
> we can easily return a value or throw an exception from the
> task?
Seems like for WAS's needs, just supporting Callable would be good
enough, no?
We need to use Runnable at the end of the day in ManagedRuntime, so that
things compile on 1.4.
-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: Dain Sundstrom [mailto:dain@iq80.com]
> Sent: Tuesday, April 24, 2007 3:29 PM
> 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 2:17 PM, Kevin Sutter wrote:
>
> > Patrick,
> >
> > On 4/24/07, Patrick Linskey <pl...@bea.com> wrote:
> >>
> >> > 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.
> >>
> >> We talked about this in a thread several months ago. I
> think that the
> >> conclusion was that it'd be neat to make our
> ManagedRuntime interface
> >> have a runInNewTransaction(Runnable) method, and to move things to
> >> use that instead of doing tx logic directly inside the sequence
> >> classes.
> >> This would be an easy change; the lack of a concrete need (i.e., a
> >> server that both denied transactional control and provided
> a means to
> >> execute a Runnable in a new tx) prevented us from changing things
> >> around.
> >
> >
> > A "concrete need" is surfacing with WebSphere. WebSphere does not
> > allow for direct transactional control (ie. suspend/resume)
> and it has
> > recently provided the means to execute a Runnable in a new
> Tx (via the
> > "runUnderUOW"
> > feature). Although WebSphere may be the exception to the
> rule, we are
> > planning on providing the mechanism so that OpenJPA can
> play in this
> > game.
>
> Kevan,
>
> Can you ask the websphere team to support a Callable also, so
> we can easily return a value or throw an exception from the
> task? It may also be important to runWithoutTx for databases
> that don't support transactional DDL, but I suppose that
> could be done with a new thread.
>
> -dain
>
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.
Re: Possible problem with ddl with only a jta-datasource and sequences
Posted by Dain Sundstrom <da...@iq80.com>.
On Apr 24, 2007, at 2:17 PM, Kevin Sutter wrote:
> Patrick,
>
> On 4/24/07, Patrick Linskey <pl...@bea.com> wrote:
>>
>> > 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.
>>
>> We talked about this in a thread several months ago. I think that the
>> conclusion was that it'd be neat to make our ManagedRuntime interface
>> have a runInNewTransaction(Runnable) method, and to move things to
>> use
>> that instead of doing tx logic directly inside the sequence classes.
>> This would be an easy change; the lack of a concrete need (i.e., a
>> server that both denied transactional control and provided a means to
>> execute a Runnable in a new tx) prevented us from changing things
>> around.
>
>
> A "concrete need" is surfacing with WebSphere. WebSphere does not
> allow for
> direct transactional control (ie. suspend/resume) and it has recently
> provided the means to execute a Runnable in a new Tx (via the
> "runUnderUOW"
> feature). Although WebSphere may be the exception to the rule, we are
> planning on providing the mechanism so that OpenJPA can play in
> this game.
Kevan,
Can you ask the websphere team to support a Callable also, so we can
easily return a value or throw an exception from the task? It may
also be important to runWithoutTx for databases that don't support
transactional DDL, but I suppose that could be done with a new thread.
-dain
RE: Possible problem with ddl with only a jta-datasource and sequences
Posted by Patrick Linskey <pl...@bea.com>.
> suspend/resume) and it has recently provided the means to
> execute a Runnable in a new Tx (via the "runUnderUOW" feature)
Yay!
It should be very easy to restructure our existing code to move the
relevant logic to a Runnable.
-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: Kevin Sutter [mailto:kwsutter@gmail.com]
> Sent: Tuesday, April 24, 2007 2:18 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: Possible problem with ddl with only a
> jta-datasource and sequences
>
> Patrick,
>
> On 4/24/07, Patrick Linskey <pl...@bea.com> wrote:
> >
> > > 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.
> >
> > We talked about this in a thread several months ago. I
> think that the
> > conclusion was that it'd be neat to make our ManagedRuntime
> interface
> > have a runInNewTransaction(Runnable) method, and to move
> things to use
> > that instead of doing tx logic directly inside the sequence classes.
> > This would be an easy change; the lack of a concrete need (i.e., a
> > server that both denied transactional control and provided
> a means to
> > execute a Runnable in a new tx) prevented us from changing things
> > around.
>
>
> A "concrete need" is surfacing with WebSphere. WebSphere
> does not allow for direct transactional control (ie.
> suspend/resume) and it has recently provided the means to
> execute a Runnable in a new Tx (via the "runUnderUOW"
> feature). Although WebSphere may be the exception to the
> rule, we are planning on providing the mechanism so that
> OpenJPA can play in this game.
>
> Kevin
>
> -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: David Jencks [mailto:david_jencks@yahoo.com]
> > > Sent: Tuesday, April 24, 2007 10:53 AM
> > > To: open-jpa-dev@incubator.apache.org
> > > Subject: Possible problem with ddl with only a jta-datasource and
> > > sequences
> > >
> > > 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
> > >
> > >
> >
> > 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.
> >
>
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.
Re: Possible problem with ddl with only a jta-datasource and sequences
Posted by Kevin Sutter <kw...@gmail.com>.
Patrick,
On 4/24/07, Patrick Linskey <pl...@bea.com> wrote:
>
> > 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.
>
> We talked about this in a thread several months ago. I think that the
> conclusion was that it'd be neat to make our ManagedRuntime interface
> have a runInNewTransaction(Runnable) method, and to move things to use
> that instead of doing tx logic directly inside the sequence classes.
> This would be an easy change; the lack of a concrete need (i.e., a
> server that both denied transactional control and provided a means to
> execute a Runnable in a new tx) prevented us from changing things
> around.
A "concrete need" is surfacing with WebSphere. WebSphere does not allow for
direct transactional control (ie. suspend/resume) and it has recently
provided the means to execute a Runnable in a new Tx (via the "runUnderUOW"
feature). Although WebSphere may be the exception to the rule, we are
planning on providing the mechanism so that OpenJPA can play in this game.
Kevin
-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: David Jencks [mailto:david_jencks@yahoo.com]
> > Sent: Tuesday, April 24, 2007 10:53 AM
> > To: open-jpa-dev@incubator.apache.org
> > Subject: Possible problem with ddl with only a jta-datasource
> > and sequences
> >
> > 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
> >
> >
>
> 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.
>
RE: Possible problem with ddl with only a jta-datasource and sequences
Posted by Patrick Linskey <pl...@bea.com>.
> 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.
We talked about this in a thread several months ago. I think that the
conclusion was that it'd be neat to make our ManagedRuntime interface
have a runInNewTransaction(Runnable) method, and to move things to use
that instead of doing tx logic directly inside the sequence classes.
This would be an easy change; the lack of a concrete need (i.e., a
server that both denied transactional control and provided a means to
execute a Runnable in a new tx) prevented us from changing things
around.
-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: David Jencks [mailto:david_jencks@yahoo.com]
> Sent: Tuesday, April 24, 2007 10:53 AM
> To: open-jpa-dev@incubator.apache.org
> Subject: Possible problem with ddl with only a jta-datasource
> and sequences
>
> 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
>
>
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.
Re: Possible problem with ddl with only a jta-datasource and sequences
Posted by Michael Dick <mi...@gmail.com>.
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 <mp...@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
> >
>
Re: Possible problem with ddl with only a jta-datasource and sequences
Posted by Kevin Sutter <kw...@gmail.com>.
On 4/25/07, Patrick Linskey <pl...@bea.com> wrote:
>
> > 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.
>
> I think that the issue at the time was that some people were unwilling
> to expose begin / commit / rollback / suspend / resume APIs, but sadly
> nobody (on either side of the debate) realized that a compromise
> executeRunnableInNewTransaction(Runnable) would be acceptible all
> around.
I think that's an accurate summary.
Kevin
-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 3:48 PM
> > To: open-jpa-dev@incubator.apache.org
> > Subject: Re: Possible problem with ddl with only a
> > jta-datasource and sequences
> >
> > 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
> > > 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.
> >
> > 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.
> >
> > Craig
> > >
> > > -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.
> >
> > 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.
>
RE: Possible problem with ddl with only a jta-datasource and sequences
Posted by Patrick Linskey <pl...@bea.com>.
> 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.
I think that the issue at the time was that some people were unwilling
to expose begin / commit / rollback / suspend / resume APIs, but sadly
nobody (on either side of the debate) realized that a compromise
executeRunnableInNewTransaction(Runnable) would be acceptible all
around.
-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 3:48 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Re: Possible problem with ddl with only a
> jta-datasource and sequences
>
> 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
> > 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.
>
> 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.
>
> Craig
> >
> > -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.
>
> 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.
Re: Possible problem with ddl with only a jta-datasource and sequences
Posted by Craig L Russell <Cr...@Sun.COM>.
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
> 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.
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.
Craig
>
> -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.
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!
RE: Possible problem with ddl with only a jta-datasource and sequences
Posted by Patrick Linskey <pl...@bea.com>.
> 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.
Re: Possible problem with ddl with only a jta-datasource and sequences
Posted by Craig L Russell <Cr...@Sun.COM>.
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!
Re: Possible problem with ddl with only a jta-datasource and sequences
Posted by Marc Prud'hommeaux <mp...@apache.org>.
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
>