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 23:00:45 GMT
I understand.  The concerns with the unmatched suspend/resume are known
within WebSphere circles quite well.  I'm sure IBM was one of the voices
that objected to this functionality.  :-)

I haven't had the time yet, but I want to understand the need for the
suspend/resume functionality within OpenJPA.  In my mind, it shouldn't be
necessary. But, I haven't put a whole lot of thought into it yet...

Kevin

On 2/19/07, Craig L Russell <Craig.Russell@sun.com> wrote:
>
> Hi Kevin,
>
> Actually, I'll recant. This would not be a hack, because it does
> guarantee that the suspension of the transaction is only for the
> duration of the method call. IIRC, when we were discussing the
> functionality of the TransactionSynchronizationRegistry, and
> considered adding useful features like "suspend" and "resume", there
> were objections that this might result in unmatched suspend/resume
> pairs, which would be a reasonable use case.
>
> The biggest downside to the proposal here is that it requires more
> setup in a server environment. The suspend/resume component would
> have to be deployed in each ear where it was needed, or deployed as a
> shared component (which is still not portable Java EE behavior IIRC).
>
> Craig
>
> On Feb 19, 2007, at 12:37 PM, Kevin Sutter wrote:
>
> > Excellent use of the Java EE features!  :-)
> >
> > Kevin
> >
> > On 2/19/07, Craig L Russell <Craig.Russell@sun.com> wrote:
> >>
> >> 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