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 00:37:24 GMT
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).  Wouldn't that be the preferred (and spec
compliant) method of "nesting" transactions?

I suppose since OpenJPA already supports this "suspension" via other TM's,
is it our desire to support this mechanism for all TM's?

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!
> >
> >
>

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