В первую очередь прочитайте про средства блокировки, доступные в используемой БД.

ShultzeПо моему средства блокировки встроенные в БД не рекомендуется использовать для функциональных блокировок, вроде многократно обсуждалось. Пользователь взял документ, залочил строку, ушел пить чай, а потом selectы не идут.
Простите, но это из серии "слышал звон". Судя по профилю, Вы говорите о MSSQL, причем о его блокировках строк. Я не разбираюсь в MSSQL, но не так давно некто Merle при участии pkarklin рассказывали мне о наличии встроенного механизма для, как Вы говорите, функциональных блокировок, в MSSQL, не мешающих никаким селектам.

ShultzeЯ бы остановился на варианте таблицы блокировок
Безусловно, всегда интереснее делать велосипед своими руками. Но как ленивый человек, я бы скорее всего остановился на использовании dbms_lock

Тут обсуждение этой же проблемы
И говорится правильное решение - dbms_lock :)

Механизмы sp_getapplock ИМХО, недостаточно гибок.....
Тут - не могу и не хочу спорить. Имхо, это вполне соответствует указанному мной принципу - посмотреть средства, которые может предоставить сервер. И если они не подходят, приниматься за велосипед.

Опять же, блокировки можно вынести в слой сервера приложений и вообще базу не трогать.
И только ради этого вводить сервер приложений? :)

Кстати, Kostt, судя по профилю ваяет СУБД на MSSQL, а клиента на .NET. Что полностью согласуется с моими рекомендациями.
Если начинать закапываться в детали, то я не нашел в указанных Вами недостатках sp_*lock чего-то, что принципиально мешало бы указанному Kostt режиму работы :)