jswong05 (5/23/2012)
This is one of the stupid design.
Imagine old days, you go to library asking for a book for a page you need. It is checked out (locked), so you cannot have it except wait.
Modern days, the librarian runs a digital replica of that page for you. It is called multi-versioning. (digital hash can be replicated) You got what you asked for as the moment it was.
Locking is not the solution (maybe it was back then at stone age)
Certain things are required to be placed under exclusive locks. That is why ACID was designed/discussed. The lock should be at a minimal unit. That is why data is at best under row level lock.
so what is the design background for "sp_getapplock" to be useful?
BOL--it says: Places a lock on an application resource.
Why do you want to do that? (just because there is no better way known doing it so chosen a bad way doing it)
Jason
I'm thinking that without a deeper understanding of the application that its hard to decide whether the design is good or bad.
Also keep in mind that these are not REAL locks, they are semaphores that are honored by the application. For example if you have one piece of code that uses this and one that doesn't the one that doesn't won't be prevented from working if there are "locks".
Now with all that said, I am not a fan of the sp_getapplock methodology. And I have, in the past, written processes that use semaphore based locking. This is something I try and avoid.
CEWII