Merlin Moncure wrote:
> There is no 100% correct answer to this problem. However, you are
> thinking in terms of pessimistic locking (like most people do), so by
> all means use it.
>
> By 'lost update' problem, I assume you mean
> user A reads
> user B reads
> user A writes
> user B writes <-- overwrites user A's changes
>
> I suggest you read up on locking strategies. Pessimistic is the easiest
> way to solve this problem but rarely the best way. Worst problem here
> is you are blocking on reads which (drastically) lowers concurrency and
> forces your app to be prepared to handle read failures...this can be a
> huge headache.
>
> Pure optimistic locking (in example above) is obviously not suitable in
> multi user applications if you care about your data. However, you could
> use timestamps + assertions to throw an error during an update if you
> are out of synch with the server here. The major difference here is
> that you are making user aware of problem when it happens, not when your
> app thinks it might happen. This type of lock resolution can be made
> via rules, triggers, or a specialized dynamic sql procedure to resolve
> the record.
>
> also, this is off-topic for odbc list :)
>
> merlin
>
>
>
sure it is big problem, but i think you can solve it with different
locking types.
if you have a write look and no read looks it should work.
i mean if you never ban the reading of the data but you guarantee with
write locks
than only one user can have a record in write-mode everything is fine
and nothing is slow.
and this is the point where i want to pop up a dialog with the message
that someone else edit the record yet.