Re: Concurrency vs. Consistency -- A traditional question

On Fri, 29 May 1998 19:05:48 +0800, "Zzzzz..." <sswan_at_hk.super.net.NOSPAM> wrote:

>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".

Probably not acceptable, although surprisingly common.

>
>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?

In PowerBuilder, Delphi or C++ you can build support for this into your ancestor objects/classes. Ensure rowid is retrieved to allow fast locking. Generally people do not start making changes and then change their minds.

>
>Option 3: Check for column values
>Have to code different stuff for different tables!

Again, in PB, delphi or C++ you should be able to determine the columns retrieved at run-time in your ancestor objects/classes. For PL/SQL and possibly VB, you can generate the code easily enough from the database schema, remembering not to modify the generated code, so it can be regenerated easily when the schema changes.

>Option 4: Add a timestamp column
>Have to do it for every table!

For oracle you would have to use a sequence (system change number?) because date columns hold times to only 1 second resolution. PL/SQL allows time determination to 1/100ths of a second but this is still not adequate. This is the easiest approach to use.

>Option 5: Set serializable to true
>Does it work ?

Not recommended according to Oracle manuals because of the performance cost.

>
>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.
>
>
>Thanks.
>
>P.S. Please remove .NOSPAM in my email address if reply my email.
>
>
Received on Sat May 30 1998 - 05:54:43 CDT