Craig, On 2/19/07, Craig L Russell <[EMAIL PROTECTED]> wrote:
On Feb 19, 2007, at 4:37 PM, Kevin Sutter wrote: > On 2/19/07, Patrick Linskey <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> > 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] >> > >> > 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] >> > P.S. A good JDO? O, Gasp! >> > >> > >> Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
