From open-jpa-dev-return-2274-apmail-incubator-open-jpa-dev-archive=incubator.apache.org@incubator.apache.org Tue Feb 20 02:54:23 2007 Return-Path: Delivered-To: apmail-incubator-open-jpa-dev-archive@locus.apache.org Received: (qmail 97214 invoked from network); 20 Feb 2007 02:54:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 20 Feb 2007 02:54:22 -0000 Received: (qmail 26117 invoked by uid 500); 20 Feb 2007 02:54:30 -0000 Delivered-To: apmail-incubator-open-jpa-dev-archive@incubator.apache.org Received: (qmail 26011 invoked by uid 500); 20 Feb 2007 02:54:30 -0000 Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: open-jpa-dev@incubator.apache.org Delivered-To: mailing list open-jpa-dev@incubator.apache.org Received: (qmail 26002 invoked by uid 99); 20 Feb 2007 02:54:30 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Feb 2007 18:54:30 -0800 X-ASF-Spam-Status: No, hits=2.3 required=10.0 tests=HTML_MESSAGE,MAILTO_TO_SPAM_ADDR,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of kwsutter@gmail.com designates 64.233.184.239 as permitted sender) Received: from [64.233.184.239] (HELO wr-out-0506.google.com) (64.233.184.239) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Feb 2007 18:54:19 -0800 Received: by wr-out-0506.google.com with SMTP id i20so1718015wra for ; Mon, 19 Feb 2007 18:53:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=k1eUTbXaC97BcFrCogGFjrK3gvuRvpi4V/jyynCa/ManDCGSMmU/HbvTcVJs5TwiF79P5c5pNF5adLWqz3Kyba6SMhl8niaa8V4VAGYMdiXvblGvvZE5ooqlsEsQJE7VtJgUkt79ZFPeklHPA2eZqrD6E+szT3+ddBEGDB2whTA= Received: by 10.114.107.19 with SMTP id f19mr3179571wac.1171940037294; Mon, 19 Feb 2007 18:53:57 -0800 (PST) Received: by 10.115.55.10 with HTTP; Mon, 19 Feb 2007 18:53:57 -0800 (PST) Message-ID: <89c0c52c0702191853y5be0a982ucb49bdd2f85f5b9d@mail.gmail.com> Date: Mon, 19 Feb 2007 20:53:57 -0600 From: "Kevin Sutter" To: open-jpa-dev@incubator.apache.org Subject: Re: WebSphere and transaction managers In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_49665_22943283.1171940037217" References: <7D856CDFE035FF45A0420ACBD71BDD6303454723@repbex02.amer.bea.com> <8e68c8e90702161120k26f24461qb3fd48d3e00b6ae0@mail.gmail.com> <7D856CDFE035FF45A0420ACBD71BDD6303454898@repbex02.amer.bea.com> <89c0c52c0702190814r2a795446ucc6623fc973af045@mail.gmail.com> <69011FB1-012E-4453-877C-DB702D72180F@SUN.com> <7D856CDFE035FF45A0420ACBD71BDD6303454CCA@repbex02.amer.bea.com> <89c0c52c0702191637va5e1328ibff496f9697cd011@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_49665_22943283.1171940037217 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Craig, On 2/19/07, Craig L Russell wrote: > > > On Feb 19, 2007, at 4:37 PM, Kevin Sutter wrote: > > > On 2/19/07, Patrick Linskey 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 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 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 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! > > > ------=_Part_49665_22943283.1171940037217--