| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: C/S Concurrency issue
A copy of this was sent to Adrian Hands <AHands_at_sprynet.com>
(if that email address didn't require changing)
On Tue, 19 May 1998 21:13:49 -0400, you wrote:
>> UPDATE T set COUNTER = COUNTER+1 where NAME = 'value';
>> SELECT MAX(COUNTER) into :my_var FROM T where NAME = 'value';
>
>That's no solution:
>
>Client #1 updates the counter to 100
>Client #2 updates the counter to 101
>Client #1 selects 101
>Client #2 selects 101
>
>oops!
>
>The sequence/serial... solution is best, but it looses points for not
>being portable.
>
>You could put a unique index on the table being updated/inserted, check
>for failures and retry, but watch out for deadlocks.
Umm, try it sometime. Unless you put a commit between the update and the select, the UPDATEs will serialize (we only let one person update a row at a time and all).
So, the scenario you laid out:
doesn't happen since client 2 is blocked until client 1 commits (and he doesn't until he selects out the counter).
thats why I reversed the order of operations in the first place. Originally they had SELECT and then UPDATE. That could lead to the condition you describe.
Thomas Kyte
tkyte_at_us.oracle.com
Oracle Government
Herndon VA
http://govt.us.oracle.com/ -- downloadable utilities
Anti-Anti Spam Msg: if you want an answer emailed to you, you have to make it easy to get email to you. Any bounced email will be treated the same way i treat SPAM-- I delete it. Received on Tue May 19 1998 - 20:32:26 CDT
 |
 |