Так и устроено - в табличку пишется тип и код блокируемого обьекта, дата блокировки, код сессии и пользователь. Перед попыткой изменения записи вызывается ХП, которая ругается, если блокировка другой сессии есть и вешает свою, если блокироки еще нет. Для 100% гарантии вешается ее же вызов на триггера изменения и удаления, только с указанием флага, не проводить блокировку, а только проверить, не блокирована ли запись другой сессией. Так же, после успешного завершения сохранения, клиентской частью вызывается та же ХП, удаляющая блокировку (в идеале делает предок изменения записей, где вначале при открытии идет попытка блокировать обьект, а после удачного сохранения - снятие блокировки и потом все окна изменения наследуются от него). Так же в БД написанно событие EVENT ON DISCONNECT, которое автопилотом вызывается СУБД на отвалившуюся или отсоединившуюся сессию и код внутри нее чистит по коду сессии висящие блокировки из таблицы блокировок. Таким образом гарантируется отсутствие мусора в таблице блокировок и наличие механизма их снятия - администратору достаточно убить сессию, которая повесила на долгое время блокировку на изменение документа (хочу заметить именно документа, что может быть по понятиям гораздо обширнее, чем одна таблица и одна запись) или же если у сервера выставлен timeout idle, он сам убьет бездействующую сессию, таким образом инициализировав чистку блокировок по ней.

Думаю, в Оракле есть аналогичный механизм EVENT-ов (или еще чего, может просто по другому называется), который позволяет на различные события сервера вызывать свой код, в т.ч. и на CONNECT/DISCONNECT сессий. Пользоваться же блокировками сервера в своих личных корыстных целях думается не есть хорошо, ресурснозатратно и не известно к чему плохому может привести.