Re: Concurrency vs. Consistency -- A traditional question

On Fri, 29 May 1998 19:05:48 +0800, Zzzzz... <sswan_at_hk.super.net.NOSPAM> wrote:
>A traditional question.
>
>In a >= 2 tiers application, the client fetch records to display to user.
>If user A updates a record according to its current displayed values
>while user B is doing the same, how to ensure consistency and
>at the time maintain maximum concurrency ? I have heard at least
>four options.
>
>Option 1: Do nothing
>If user A commit first, user B will miss user A's update and is not
>looking at the "current displayed values".
>
>Option 2: Select for update
>Have to do it for every screen! When should I do it? If I check for the
>'ItemChanged' event, what if a user changes a value but lately undoes it? I
>will lost a lot of concurrency ! If I do just before update, what's the
>different of it and Option 1?
>
>Option 3: Check for column values
>Have to code different stuff for different tables!
>
>Option 4: Add a timestamp column
>Have to do it for every table!
>
>Option 5: Set serializable to true
>Does it work ?
>
>I know that many front-end will do it for you. But......what if I'm using
>stored procedures to encap. everything and is bypassing stuffs like
>DataWindows
>, or in a Web environment?
>
>What are you using? Can anybody share his/her experience?
>I am using Oracle v7.3, PowerBuilder/Visual Basic. But this should be
>'generic' enough for any back-end/front-end.

It is very difficult to make it generic enough for any back-end, since there are different definitions of locking and different sets of functionality.

So the traditional answer is it depends on how maximum your concurency needs to be. Different db vendors have different ideas on how these things should work, and are somewhat incompatible. You can either try to deal with every possible situation (perhaps through environment variables), deal with every situation that comes up, use your own locking, or choose option 1.

>
>
>Thanks.
>
>P.S. Please remove .NOSPAM in my email address if reply my email.
>
>

--
These opinions are my own and not necessarily those of Information Quest

or Pebble In The Sky                     http://www.informationquest.com

http://ourworld.compuserve.com/homepages/joel_garry jgarry@nospameiq.com
"See your DBA?"  I AM the @#%*& DBA!     Remove nospam to reply.  Sorry.