sp_getapplock is a simple way to make sure external calls don't end up stepping on each other during a shared usage.

Under most circumstances I've used to to make sure something that business 'GUARANTEED!' would never be ran simultaneously by two users literally couldn't be ran simutaneously by two users.

An example. Let's say you've got a user-initiated process to go and bulk load data into a staging table from user-delivered files to your FTP site. Users want to initiate it themselves because sometimes they want to human-QA them before dumping them to the system.

Without something like this in place, two users could theoretically step on each other running the same process. With it, you can make sure that one runs to completion (and thus not mucking up staging data) while the other waits... or gets denied based on another user's usage.

sp_applock has its uses, particularly for user-initiated events that require dedicated processing during its existance. It's not used to block reads or the like (as jswong seems to be intimating), it's used to help isolate resources to a specific instance of a process. However, it definately has its downsides. Crash, failure to complete, etc keeps the applock in existance until a DBA becomes involved to cleanup the leftovers and release the applock.

Sometimes, that's a GOOD thing... and another reason I've used it, to make sure a 10 minute repetitive process that failed for some reason during the last process literally CANNOT fire up again until manual intervention.

applock is nothing more than iteration/multi-instance defense from your users in your data-systems. Any time you look at something you've built and decide "If this occurs more than once simultaneously we're hosed" and you can't figure out how to re-design it to NOT have that problem, sp_applock is your new best friend.

It's like any other tool. If you misuse your screwdriver as a wrench it won't work right.