Answers

1) Yes. We update all columns.
2) True. Yup we lock the row or in the case of a complex entity we lock the header row which implies locks on teh child tables.

3) Yes. That is true we dont need these mechanisms.


We do use a lock table that contains table/entity/process name, key, user, date, lock notes, etc....

Long lunch synmdrome or dead workstation is done via the age of the lock.
Old locks can be overridde, in the case of the dead workstation the same user can reposess there lock.

We generally have a clean locks routine incase of bugs or buildup.

The reason...When we started doing database work (even in the foxpro days) we used the same approach. So we did our best to take it to the SQL world and it has seemed to work OK for us.

We also have the ability to turn locks off as well. In a lot (not all) of web apps we dont worry about contention as much as the owner of teh data is the one manipulating it. Like in amazon the customer owns the record until a certain point and they are allowed to make changes to there order/customer info/etc....

What approach do you use ?
>So:
>
>1) The SP receives and updates all fields every time.
>
>2) Contention management is via a pessimistic locking mechanism. Effectively you lock the entire row/s when a user enters edit mode.
>
>3) Therefore you don't need dataset/entity change tracking.
>
>How does the lock work- do you maintain a lock table with table name and primary key? Are you locking records in SQL server as well? Or are you wrapping the whole edit process in some sort of long-lived transaction?
>
>How do you handle "lunch lock"- is there a cleaner process that runs periodically to unlock permanently locked records?
>
>I'm curious to know why you chose this approach. Usually pessimistic locking is regarded as a less desirable methodology, isn't it?