А информация, за кем заблокирована запись, критична? Если нет - выкидывайте поле BlockedBy, select ... for update сам накладывает на выбранные строки RX-блокировку. Факт наличия блокировки из других сессий определяется попыткой все тем же select ... for update nowait (да, здесь нужна опция nowait) - при наличии блокировки на запрашиваемый ресурс вылетит ORA-00054: resource busy and acquire with NOWAIT specified.
Поле при сбое остается заполненным из-за того, что сервер фиксирует транзакцию, в ходе которой выполняется update Table1 set BlockedBy = User_Id where Id = 1 - могу посоветовать ловить в нужных местах exceptions на клиенте, и при их наличии снимать флаг блокировки. Но это не самый лучший выход, т.к. блокировать ресурс на время действий пользователя, и снимать блокировку по user events в большинстве случаев просто неприемлемо - представьте себе, что пользователь залочил запись, а потом пошел обедать. Или ушел домой, а наутро уехал в командировку, не разлочив запись. Что будут делать те, кому эта запись нужна? Обычно наложение блокировки, DML, и снятие блокировки по commit/rollback проходят в контексте одной транзакции.
P.S. Если все же интересно, кто удерживает запись - можно обратиться к DBA_DML_LOCKS.

Сахават ЮсифовДык, он после селекта отключается. Какая там блокировка.
Да я все это приекрасно понимаю, поэтому и говорю, что блокировать записи и производить изменения надо в контексте одной транзакции.