Bob,
I'm not sure I understand why you're using a GUID? Session.SessionID
or some other ID that would help identify the user, client or session
currently locking for diagnostic purposes would be better.
Not everyone uses sessions. GUIDs can be used whether sessions are enabled
or not.
I was just trying to create a generic solution, trusting that the OP would
be able to adapt it to his situation. To amplify:
If you're using sessions, and have taken precautions against
session-hijacking, use SessionID instead of Guid
If you are on a LAN or WAN, and your site has anonymous disabled and
Integrated autentication enabled, use the user's login name instead of the
GUID
If you are using Basic Authentication and your user logs into a database
that returns a unique user id, use the id instead of the GUID
'do stuff
Also after your code times out failing to get a lock the code goes on
to to it's stuff anyway.
Oops ... er ... I left that as an exercise for the reader ... yeah, that's
the ticket!
Come on reader (not you, Anthony - I know you know the answer <grin>)! What
has to be changed in the above snippet to make it not go to the "do stuff"
part!