openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: WebSphere and transaction managers
Date Tue, 20 Feb 2007 01:23:05 GMT

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

>
> 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
View raw message