Matt Adamson wrote:
Guys,
We have an issue where we need to control access to specific web
pages e.g. if one user is editing a purchase requisition another user
shouldn't be able to perform any actions on it.
I presume we could lock the purchase requisition for editing by a
specific user when an edit button is pressed. Only that user would
then be able to edit the document. However can anyone think of any
better approaches to this issue which I presume must be quite common
in other application domains
You need to think about ths requirement a little more. Pessimistic locking,
while commonplace in stateful client-server applications, is problematical
in stateless http applications. For example: user A locks a record for
editing. User B wants to edit the same record but can't until user A is
finished. What happens if user A is called away from his machine and never
comes back ... or user A's machine dies.
And what is pessimistic locking going to solve? With optimistic locking, the
last user to save his changes "wins". For example, users A and B are editing
the same record. User A finishes editing it and saves. User B then does the
same. User B's changes stick because the last update "wins". The only
difference with pessimistic locking is that the second user is notified that
someone else is editing the record before he starts editing. But even so,
the last update will "win": user A starts editing, lodking the record. User
B attempts to start and is informed that he has to wait. User A finishes
editing and unlocks the record. User B starts editing and saves his changes.
Again, the last update wins ... no diffeerence, really. The lack of
notification in optimistic locking can be mitigated by the application
keeping track of the original statem of the record when itis initially
retrieved for editing. At update time, it can first check to see if the
record has changed* since it was retrieved, and notify the user that
somebody else updated the record while he was working on it. The user can
then decide if he wants to see the changes made by the other user before
making the decision as to whether his changes should be discarded, or used
to overwrite the other user's changes. I would assume some communication
between the two users will occur since they can likely pick up a phone and
talk to each other (or walk down the hall t the other's cubicle).
If, despite my efforts to convince you otherwise, you still feel like you
need pessimistic locking, then how it is implemented really depends on the
type and version of database you are using (never ask a database-related
question without providing this information: it's almost alway relevant).
* In SQL Server, a column of type "timestamp" can be used to detect changes
to a record. The name of the datatype is misleading: it has nothing to do
with time. What it is is a unique value representing the "version" of a
record: it changes whenever an update is made to any of the columns in te
record.
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
