From open-jpa-dev-return-3177-apmail-incubator-open-jpa-dev-archive=incubator.apache.org@incubator.apache.org Thu Apr 05 18:35:31 2007 Return-Path: Delivered-To: apmail-incubator-open-jpa-dev-archive@locus.apache.org Received: (qmail 70584 invoked from network); 5 Apr 2007 18:35:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Apr 2007 18:35:30 -0000 Received: (qmail 39251 invoked by uid 500); 5 Apr 2007 18:35:37 -0000 Delivered-To: apmail-incubator-open-jpa-dev-archive@incubator.apache.org Received: (qmail 39119 invoked by uid 500); 5 Apr 2007 18:35:37 -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 39110 invoked by uid 99); 5 Apr 2007 18:35:37 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Apr 2007 11:35:37 -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 wisneskid@gmail.com designates 64.233.184.230 as permitted sender) Received: from [64.233.184.230] (HELO wr-out-0506.google.com) (64.233.184.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Apr 2007 11:35:29 -0700 Received: by wr-out-0506.google.com with SMTP id i31so481640wra for ; Thu, 05 Apr 2007 11:35:09 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=M8mFqRscb/EKc05wftDt8YQ87CLjQztWJNqyGEpVr5Y7VDgEgcxdOQQIdS5BuE4JtocKLKF84cCtIbJUtHYzmqexU7+At/YsP1F66HBJku3UsfpL4HFvziccTa+CAXtZz4j8HfbLdeiMHIoQJiuoxeYhiMD2t1BTj1EcjrpjBjM= 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:content-transfer-encoding:content-disposition:references; b=ufZe7oVT7WFcUytIW/QIEQIAXEIhAYfpwecm3frCaoF3bFEvncd8V/9Hu9A2FynBsLBAKo4Ljk6HRe86NUilkjKm25mxKfOb07OfLGhx5fvPeC3ZwfRogIcI0u9VJlMzqDupoF6hdKD5u7kNqr3eLhvWuid93PubV/KbE3QgHYs= Received: by 10.114.56.1 with SMTP id e1mr826685waa.1175798108153; Thu, 05 Apr 2007 11:35:08 -0700 (PDT) Received: by 10.114.127.9 with HTTP; Thu, 5 Apr 2007 11:35:08 -0700 (PDT) Message-ID: <864cafc0704051135h35861df5t707af70745d25570@mail.gmail.com> Date: Thu, 5 Apr 2007 11:35:08 -0700 From: "David Wisneski" To: open-jpa-dev@incubator.apache.org Subject: Re: [jira] Commented: (OPENJPA-182) db2 update lock syntax WITH USE AND KEEP UPDATE LOCKS In-Reply-To: <31989240.1175790932560.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <10767081.1174929812132.JavaMail.jira@brutus> <31989240.1175790932560.JavaMail.jira@brutus> X-Virus-Checked: Checked by ClamAV on apache.org Patrick, We were unaware that fetch plan properties could be set as Hints. Now that we look at the code we see this, but we did not find this when we read the OpenJPA documentation. The only hint we found in the documentation was the OracleSelectHint and so our design was based on how OracleSelectHint was implemented. OracleSelectHint is not implemented as a FetchPlan property. Why don't you integrate your patch and then we will rerun our tests to make sure the function works as we had originally intended. On 4/5/07, Patrick Linskey (JIRA) wrote: > > [ https://issues.apache.org/jira/browse/OPENJPA-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487046 ] > > Patrick Linskey commented on OPENJPA-182: > ----------------------------------------- > > > > Hopefully, this will be useful for applications where there are "hot" tables > > > that require pessimistic locking even though the rest of the application > > > does better with optimistic. > > > > That's what our lock levels and lock APIs are for. I'm still not clear on what this is > > adding to the mix for most DBs. > > Not really -- the lock levels allow the user to configure how locking should happen, not what the isolation level should be for the locks. > > I don't know about what levels of support non-DB2 databases have for per-query isolation level configuration. Does anyone have any experience with this in other databases? > > Oh, and regardless, we should change the base DBDictionary to throw an exception if this FetchPlan setting is set but not serviceable. > > One thing that we should test: I'm not convinced that the lock level override in the DB2Dictionary code is necessary. It's possible that the LockManager will already take into account the current JDBCFetchConfiguration's lock level settings when specifying the forUpdate setting for the toSelect() clause. Some test cases will make it easy to figure out the answer to this question. > > > 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 > > Assigned To: David Wisneski > > Attachments: OPENJPA-182.patch, openJPA182.patch > > > > > > 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. > >