Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!drn.maxwell.syr.edu!news.maxwell.syr.edu!postnews.google.com!o13g2000cwo.googlegroups.com!not-for-mail
From: "Tony Andrews" <andrewst@onetel.com>
Newsgroups: comp.databases.theory
Subject: Re: Theoretical Basis for SELECT FOR UPDATE
Date: 3 Oct 2005 05:09:28 -0700
Organization: http://groups.google.com
Lines: 22
Message-ID: <1128341368.088540.116220@o13g2000cwo.googlegroups.com>
References: <1128057843.378642.38150@z14g2000cwz.googlegroups.com>
   <1128080541.493388.182640@f14g2000cwb.googlegroups.com>
   <1128083799.008542.251310@g49g2000cwa.googlegroups.com>
   <1128085148.501324.206420@g47g2000cwa.googlegroups.com>
   <1128094332.876823.68570@g47g2000cwa.googlegroups.com>
   <3q0rj15950229tgrms6580mv8svlv4iud6@4ax.com>
   <1128116366.829654.43110@z14g2000cwz.googlegroups.com>
NNTP-Posting-Host: 194.131.250.1
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1128341373 22008 127.0.0.1 (3 Oct 2005 12:09:33 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Mon, 3 Oct 2005 12:09:33 +0000 (UTC)
User-Agent: G2/0.2
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7,gzip(gfe),gzip(gfe)
Complaints-To: groups-abuse@google.com
Injection-Info: o13g2000cwo.googlegroups.com; posting-host=194.131.250.1;
   posting-account=IJrbaQwAAACC57cNvnaNWPkLUkH3QWCJ
Xref: dp-news.maxwell.syr.edu comp.databases.theory:33866

vc wrote:
> But any update in the database already locks the rows being updated.
> What is gained by the comma operator ?  If you mean that concurrent
> select operations will be blocked during a set of comma delimited
> operators execution,  then in fact you convert all database
> transactions from being concurrent to serial.  If I misunderstood you,
> please elaborate.

No, the comma operator has nothing to do with other, concurrent
transactions really.  It has to do with making the transaction atomic
*from the perspective of the session performing the operation*.  Gene
has already given a good example about printing information half-way
through the transaction; that might look like this:

update account set bal=bal+10 where ac_no=123;
call print_total_balance_for_all_accounts;
update account set bal=bal-10 where ac_no=456;
commit;

The TTM version would make it impossible to print the intermediate
total (which would be 10 higher than it should be).