Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 5272 invoked from network); 28 Oct 2005 15:30:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 28 Oct 2005 15:30:11 -0000 Received: (qmail 11974 invoked by uid 500); 28 Oct 2005 15:30:10 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 11944 invoked by uid 500); 28 Oct 2005 15:30:10 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 11935 invoked by uid 99); 28 Oct 2005 15:30:10 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Oct 2005 08:30:10 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [67.116.30.6] (HELO red.amberpoint.com) (67.116.30.6) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Oct 2005 08:30:05 -0700 Received: from [127.0.0.1] (bp-work.edgility.com [10.10.11.66]) by red.amberpoint.com (8.12.11/8.12.11) with ESMTP id j9SFTlOV002544 for ; Fri, 28 Oct 2005 08:29:47 -0700 (PDT) Message-ID: <436243E9.9000901@amberpoint.com> Date: Fri, 28 Oct 2005 08:29:45 -0700 From: Bryan Pendleton User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: derby-dev@db.apache.org Subject: Re: [jira] Commented: (DERBY-231) "FOR UPDATE" required for updatable result set to work References: <1704929109.1130428142358.JavaMail.jira@ajax.apache.org> <4360FD53.90704@debrunners.com> <4361EFF6.4040109@sun.com> <17250.10385.845154.568186@gargle.gargle.HOWL> <43622B4C.8040101@sun.com> <17250.12151.523502.149664@gargle.gargle.HOWL> In-Reply-To: <17250.12151.523502.149664@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N > the current Derby semantics (releasing > the update lock once a next() is executed), isn't very helpful. Even in read-committed isolation level, it still seems like it might be useful to be able to control the lock-mode on the current row. If I have an read-committed transaction which reads through many rows, and chooses to update a subset of them, being able to communicate to the DB that I'd like an update-mode lock when I read the record, to be either (a) released when I do Next or (b) promoted to exclusive-mode if I happen to update this record, seems like a useful behavior to me. That is, I think that update-mode locks can be useful in reducing deadlock, and I think that's true even when running at read-committed isolation level. thanks, bryan