openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: WebSphere and transaction managers
Date Mon, 19 Feb 2007 16:14:50 GMT
The WebSphere Transaction API does not allow for suspension of a
transaction.  Even if we move to the "official" JPA transaction API
(TransactionSynchronizationRegistry), there is no suspend method available.
I would have to better understand OpenJPA's need for the transaction
suspension before determining whether there are alternatives available.

On 2/16/07, Patrick Linskey <plinskey@bea.com> wrote:
>
> From what the user said, it sounds like another solution is to use a
> different ManagedRuntime that allows suspension. My guess is that this
> is not an "official" IBM API, and is the reason that we're not using it.
> Is there some other official means by which we could change
> WASManagedRuntime to allow suspend etc.?
>
> In short, if we solve OPENJPA-149, then we have the easiest-of-all
> pathways covered, and OPENJPA-153 is less important.
>
> -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: Albert Lee [mailto:allee8285@gmail.com]
> > Sent: Friday, February 16, 2007 11:21 AM
> > To: open-jpa-dev@incubator.apache.org
> > Subject: Re: WebSphere and transaction managers
> >
> > This is known problem in WAS. The reason is data source
> > created in WAS is
> > always enlisted in the current global transaction, therefore
> > RESOURCE_LOCAL
> > persistence unit using WAS data source triggers the observed behavior.
> >
> > This limitation will be corrected in the WAS EJB3 Feature
> > Pack and future
> > releases.
> >
> > Immediate solution is not to specify the non-jta-data-source in the
> > persistence unit but replace with connection information
> > using properties
> >   openjpa.ConnectionUserName
> >   openjpa.ConnectionPassword
> >   openjpa.ConnectionURL
> >   openjpa.ConnectionDriverName
> >
> > It is not the ideal solution, but functional.
> >
> > Albert Lee
> >
> > On 2/16/07, Patrick Linskey <plinskey@bea.com> wrote:
> > >
> > > Hi,
> > >
> > > It looks like the new WebSphere transaction manager lookup code is
> > > missing some functionality available elsewhere.
> > >
> > > See OPENJPA-149
> > (https://issues.apache.org/jira/browse/OPENJPA-149) and
> > > OPENJPA-153 (https://issues.apache.org/jira/browse/OPENJPA-153) for
> > > details.
> > >
> > > The key problems are:
> > >
> > > OPENJPA-149: the WASManagedRuntime class throws exceptions on some
> > > methods, preventing OpenJPA from being able to suspend transactions
> > >
> > > OPENJPA-153: even when specifying a non-JTA data source,
> > the data source
> > > returned does not allow commits. It does seem like the
> > behavior of the
> > > data source is at least a bit different than the JTA data
> > source, since
> > > OpenJPA is able to call setAutoCommit().
> > >
> > > These seem like usability issues with WAS. I'm hoping that
> > someone with
> > > more WAS knowledge than me can resolve the issues easily.
> > Any takers?
> > >
> > > -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.
> > >
> >
>

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