From open-jpa-dev-return-3556-apmail-incubator-open-jpa-dev-archive=incubator.apache.org@incubator.apache.org Wed Apr 18 17:26:25 2007 Return-Path: Delivered-To: apmail-incubator-open-jpa-dev-archive@locus.apache.org Received: (qmail 91885 invoked from network); 18 Apr 2007 17:26:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 18 Apr 2007 17:26:24 -0000 Received: (qmail 63004 invoked by uid 500); 18 Apr 2007 17:26:30 -0000 Delivered-To: apmail-incubator-open-jpa-dev-archive@incubator.apache.org Received: (qmail 62972 invoked by uid 500); 18 Apr 2007 17:26: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 62963 invoked by uid 99); 18 Apr 2007 17:26:30 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Apr 2007 10:26:30 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of plinskey@bea.com designates 66.248.192.39 as permitted sender) Received: from [66.248.192.39] (HELO repmmg02.bea.com) (66.248.192.39) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Apr 2007 10:26:23 -0700 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3IHQ1VU020059 for ; Wed, 18 Apr 2007 10:26:01 -0700 Received: from repbex02.amer.bea.com (repbex02.bea.com [10.160.26.99]) by repmmr02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3IHPd6t008267 for ; Wed, 18 Apr 2007 10:26:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: RE: [jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS Date: Wed, 18 Apr 2007 10:22:04 -0700 Message-ID: <7D856CDFE035FF45A0420ACBD71BDD6303F4F775@repbex02.amer.bea.com> In-Reply-To: <7a5e6f6a0704180956q215c3840v42d89e9f7109a0b9@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS Thread-Index: AceB2q30bp5pv8kcTg6jQuUFxRnCrgAAzCjQ References: <10767081.1174929812132.JavaMail.jira@brutus> <28217454.1176847516161.JavaMail.jira@brutus> <7a5e6f6a0704180956q215c3840v42d89e9f7109a0b9@mail.gmail.com> From: "Patrick Linskey" To: x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Virus-Checked: Checked by ClamAV on apache.org > So Essentially we need to pass this subselect flag to > getForUpdateClause > method.I am not sure how would we do that without overriding > the method in > DB2Dictionary or chnaging the signatures in DBDictionary > which would affect > many other files Understood. I think that this is a bit of a tough question. On the one hand, I hate to see lots of code duplication. On the other hand, it's annoying to have unneeded concepts in other DBDictionaries. Personally, I think that I prefer adding the boolean to the DBDictionary method signature, or otherwise changing the DBDictionary method signature to pass along a select or something from which many of the boolean values could probably be inferred, or some other DBDictionary-level refactoring. Does anyone else have an opinion? -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: Ritika Maheshwari [mailto:ritikamster@gmail.com] > Sent: Wednesday, April 18, 2007 9:57 AM > To: open-jpa-dev@incubator.apache.org > Subject: Re: [jira] Commented: (OPENJPA-182) db2 update lock > syntax WITH USE AND KEEP UPDATE LOCKS > > 1. OK I think I will open a new issue for the bug > 2. I will redo the formatting > 3.To be able to use DBDictionary method we will have to > change the signature > of the > > toSelect(SQLBuffer selects, JDBCFetchConfiguration > fetch,SQLBuffer from, > SQLBuffer where, SQLBuffer group,SQLBuffer having, SQLBuffer > order,*boolean*distinct, > *boolean* forUpdate, *long* start, *long* end) > > to include a boolean flag subselect which will be computed in the > > SQLBuffer toSelect(Select sel, *boolean* > forUpdate,JDBCFetchConfiguration > fetch) > > since we have the handle to the Select here.This needs to be > done only for > DB2 because only in case of DB2 even if forUpdate is false( > which is set to > false correctly for subselects by > SQLBuffer.resolveSubselects()) we need to > append a FOR READ ONLY clause except in case of subselects.In other > databases if forUpdate is false we do not append any update > or FOR READ ONLY > CLAUSE. So this situaton is unique to db2. > > So Essentially we need to pass this subselect flag to > getForUpdateClause > method.I am not sure how would we do that without overriding > the method in > DB2Dictionary or chnaging the signatures in DBDictionary > which would affect > many other files > > > > > On 4/17/07, Patrick Linskey (JIRA) wrote: > > > > > > [ > > > https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atl assian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1248955 8] > > > > Patrick Linskey commented on OPENJPA-182: > > ----------------------------------------- > > > > Some comments: > > > > 1. I don't think that we should be doing work on resolved > issues. So, this > > should be re-opened, or (preferably) a new issue should be > opened for this > > new bug. > > > > 2. The patch you attached does not use OpenJPA-style > formatting. We don't > > have a style guide spelled out as well as we probably > should, but we always > > put spaces after commas, we indent 4 spaces on continuation > lines, and we > > put a space between an 'if' and the open paren. > > > > 3. It's a shame to have to do all this code duplication between > > DBDictionary and DB2Dictionary. To what extent can we refactor > > DBDictionary's methods to make this concept work out better for > > DB2Dictionary? > > > > > db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS > > > ------------------------------------------------------------------ > > > > > > Key: OPENJPA-182 > > > URL: > https://issues.apache.org/jira/browse/OPENJPA-182 > > > Project: OpenJPA > > > Issue Type: New Feature > > > Components: jdbc > > > Environment: db2 database driver for zOS, AS400, > Unix, Windows, > > Linux > > > Reporter: David Wisneski > > > Fix For: 0.9.7 > > > > > > Attachments: JIRA182-subselect.patch, OPENJPA-182.patch, > > OPENJPA-182.patch, openJPA182.patch, openjpa182TestCase.jar > > > > > > > > > A while back we changed the syntax of update locking from > FOR UPDATE > > OF to WITH RS USE AND KEEP UPDATE LOCKS. Additional > changes are required > > because > > > 1. if isolation=serializable is configured, then the > syntax should > > be WITH RR USE AND KEEP UDPATE LOCKS > > > 2. when using DB2/400 on iSeries machines, the syntax is > WITH RS USE > > AND KEEP EXCLUSIVE LOCKS or WITH RR USE AND KEEP EXCLUSIVE > LOCKS because > > DB2/400 only supports read or exclusive locks. > > > 3. DB2 supports both a FETCH FIRST ROWS and update > LOCKS clauses. > > > So we change supportsLockingWithSelectRange = true in the > > AbstractDB2Dictionary class and change the DB2Dictionary to > append the > > correct LOCKS syntax depending on vendor, release and > isolation level. > > > > -- > > This message is automatically generated by JIRA. > > - > > You can reply to this email to add a comment to the issue online. > > > > > 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.