openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: Possible problem with ddl with only a jta-datasource and sequences
Date Wed, 25 Apr 2007 23:51:08 GMT
On 4/25/07, Patrick Linskey <plinskey@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message