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 Tue, 20 Feb 2007 02:53:57 GMT
Craig,

On 2/19/07, Craig L Russell <Craig.Russell@sun.com> wrote:
>
>
> On Feb 19, 2007, at 4:37 PM, Kevin Sutter wrote:
>
> > On 2/19/07, Patrick Linskey <plinskey@bea.com> wrote:
> >>
> >>
> >> Maybe we should add a method to our ManagedRuntime interface to
> >> accept a
> >> Runnable that should be run in a separate transaction, and migrate
> >> our
> >> code to use that approach. That way, the WASManagedRuntime could
> >> do what
> >> Craig outlined, and other ManagedRuntime impls could retain their
> >> current behavior.
> >
> >
> > Although this approach is probably workable, this sounds more
> > complicated
> > than just requiring the use of the non-jta-data-source element.
> > WebSphere
> > will eventually support the non-jta-data-source (supposedly in the
> > next Beta
> > of the EJB3 Feature Pack).
>
> This would be welcome news, indeed.
>
> > Wouldn't that be the preferred (and spec
> > compliant) method of "nesting" transactions?
>
> I think so.
> >
> > I suppose since OpenJPA already supports this "suspension" via
> > other TM's,
> > is it our desire to support this mechanism for all TM's?
>
> I think so. Is WAS the only application server that doesn't support
> non-JTA DataSource?


Craig, I meant the ability to suspend a transaction.  It seems that OpenJPA
has provided for suspending of transactions via various API's (some
external, some internal).  So, it seems that some TM's allow for suspension
of in-flight transactions, while others (like WAS) does not.  At least not
via public API's.  Does OpenJPA need to provide this level of support for
all TM's?  That's what I meant by my question.

Craig
>
> >
> > Kevin
> >
> >
> > On 2/19/07, Patrick Linskey <plinskey@bea.com> wrote:
> >>
> >> > > I would have to better understand OpenJPA's need for the
> >> transaction
> >> > > suspension before determining whether there are alternatives
> >> > > available.
> >>
> >> The use case is that if we can suspend the tx, then the user doesn't
> >> need to provide a non-JTA data source.
> >>
> >> > The idea is to create an EJB component solely for the purpose of
> >> > suspending a transaction. This could be a Stateless Session
> >> > Bean that defines a method declared as Transaction Not Supported.
> >>
> >> Interesting. We could even mark the method as @RequiresNew, thus
> >> letting
> >> the container take care of demarcation. Certainly an interesting
> >> approach for providing similar ease-of-use in a WebSphere
> >> environment.
> >>
> >> Maybe we should add a method to our ManagedRuntime interface to
> >> accept a
> >> Runnable that should be run in a separate transaction, and migrate
> >> our
> >> code to use that approach. That way, the WASManagedRuntime could
> >> do what
> >> Craig outlined, and other ManagedRuntime impls could retain their
> >> current behavior.
> >>
> >> -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: Monday, February 19, 2007 8:33 AM
> >> > To: open-jpa-dev@incubator.apache.org
> >> > Subject: Re: WebSphere and transaction managers
> >> >
> >> > It is possible to suspend a transaction by the standard Java EE
> >> > technique. Unfortunately, this might be considered a hack, but
> >> AFAIK
> >> > it's perfectly legal.
> >> >
> >> > The idea is to create an EJB component solely for the purpose of
> >> > suspending a transaction. This could be a Stateless Session
> >> > Bean that
> >> > defines a method declared as Transaction Not Supported. The method
> >> > invocation would contain a runnable as an argument which the
> >> > execution of the method would then run. Once the runnable
> >> completed,
> >> > returning from the method would resume the suspended
> >> transaction. If
> >> > needed, an Object returned from the method could contain the
> >> results
> >> > of the method.
> >> >
> >> > Craig
> >> >
> >> > On Feb 19, 2007, at 8:14 AM, Kevin Sutter wrote:
> >> >
> >> > > 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.
> >> > >> > >
> >> > >> >
> >> > >>
> >> >
> >> > 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!
> >> >
> >> >
> >>
>
> 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!
>
>
>

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