Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 89699 invoked from network); 19 Feb 2007 19:52:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 19 Feb 2007 19:52:20 -0000 Received: (qmail 2618 invoked by uid 500); 19 Feb 2007 19:52:27 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 2588 invoked by uid 500); 19 Feb 2007 19:52:27 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 2577 invoked by uid 99); 19 Feb 2007 19:52:27 -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 11:52:27 -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 msatoor@gmail.com designates 66.249.92.171 as permitted sender) Received: from [66.249.92.171] (HELO ug-out-1314.google.com) (66.249.92.171) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Feb 2007 11:52:16 -0800 Received: by ug-out-1314.google.com with SMTP id l31so634371ugc for ; Mon, 19 Feb 2007 11:51:55 -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=hv2kVGjpcvV0NVLmVYKi9bWZ/QdAZLy/b169qhqLxTwM73m49fEhV6vg76Hh0KcbAjAx55lgP47xIVK3ofOTvc+iBdatN6ggI7TETZYC00j3i8gQzurN7h4vQmn0hXc49LOPerhmJTD1mcOmNMNClOUhM9u2scOqvZ7pmTznaoA= Received: by 10.78.204.20 with SMTP id b20mr1104728hug.1171914713323; Mon, 19 Feb 2007 11:51:53 -0800 (PST) Received: by 10.78.175.4 with HTTP; Mon, 19 Feb 2007 11:51:53 -0800 (PST) Message-ID: Date: Mon, 19 Feb 2007 11:51:53 -0800 From: "Mamta Satoor" To: "Derby Discussion" Subject: Re: Multiple connection question In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_25430_4579844.1171914713104" References: X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_25430_4579844.1171914713104 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Danny, you might find the following discussion on row locking semantic helpful http://www.nabble.com/Derby-row-locking-semantic-tf3035227.html#a8434325 Mamta On 2/19/07, Danny Gallagher wrote: > > Question about how derby behaves: > > This is at the default isolation level, I am using the latest derby > version, in > > network server mode > > > > The problem is that when one connection to the database is inserting 1000 > records into a table > > (all in one transaction) when another connection tries to select on that > table, the select is blocked > > until the 1000 record insert is committed. > > > > What I expected to see is that the select statement would execute without > having to wait, because based on > > the isolation level and the select I am asking for all committed records > that meet the criteria of the select statement. > > Why is it blocking for records that are not even committed yet? > > > > Am I missing something? > > > > Thanks > > ------------------------------ > Find a local pizza place, movie theater, and more=85.then map the best > route! Try it! > ------=_Part_25430_4579844.1171914713104 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Danny, you might find the following discussion on row locking semantic= helpful
Mamta
 
On 2/19/07, = Danny Gallagher <dgalla= gher999@hotmail.com> wrote:

Question about how derby behaves:

This is at the default isolation level, I am using the latest d= erby version, in

network server mode

 

The problem is that when one connection to the database is inse= rting 1000 records into a table

(all in one transaction) when another connection tries to selec= t on that table, the select is blocked

until the 1000 record insert is committed.

 

What I expected to see is that the select statement would execu= te without having to wait, because based on

the isolation level and the select I am asking for all committe= d records that meet the criteria of the select statement.

Why is it blocking for records that are not even committed yet?=

 

Am I missing something?

 

Thanks


Find a local pizza place, movie theater, and more=85.then map the best rout= e! Try it!

------=_Part_25430_4579844.1171914713104--