Marek Wawrzyczny <mare..sh.com.au> wrote:
> The reason pessimistic lock is preferred is that we are writing an
> application where record modifications are going to be frequent. The
> users are VERY non-technical. Optimistic locking offers only the
> following three solutions to conflicts as far as I can see:
>
> 1) Replace someone else's changes with the user's changes.
> 2) Prevent changes being saved.
> 3) Present the user with an interface to choose the correct data.
>
> We don't think the users of this particular system could cope with any
> of these choices.
I'm not saying whether you should use one or the other, but there is a
fourth option for dealing with an optimistic locking failure.
4) reload the object from the database and automatically merge in fields
which had been modified and resave.
I would think that the deciding issue would be the frequency of changes.
This archive was generated by hypermail 2.0.0 : Tue Nov 30 2004 - 18:10:35 EST