Тупик при простом обновлении: ShareLock и AccessExclusiveLock

В журналах ошибок замечал случайные тупики, причина в параллельном обновлении одной и той же строки:

[1111]:LOG:  process 1111 detected deadlock while waiting for ShareLock on transaction 123456789 after 1000.095 ms
[1111]:DETAIL:  Process holding the lock: 2222. Wait queue: .
[1111]:CONTEXT:  while locking tuple (9999999,99) in relation "ccc"
[1111]:STATEMENT:  update ccc set modification_date_time=$1, ... where id=$7
[1111]:ERROR:  deadlock detected
[1111]:DETAIL:  Process 1111 waits for ShareLock on transaction 123456789; blocked by process 2222.
    Process 2222 waits for AccessExclusiveLock on tuple (9999999,99) of relation 55555 of database 66666; blocked by process 1111.
    Process 1111: update ccc set modification_date_time=$1, ... where id=$7
    Process 2222: update ccc set modification_date_time=$1, ... where id=$7
[1111]:HINT:  See server log for query details.

В приложении происходит следующее:

1. Hibernate загружает объект (строку)
2. Поле модифицируется
3. Hibernate сохраняет объект в базе данных, что приводит к выражению UPDATE.

Непонятно, почему так происходит, ведь это просто обычное обновление, и процессы не должны зависеть друг от друга. Я понимаю, что это состояние гонки, но с точки зрения приложения это не важно.

Я не совсем понимаю, что такое ShareLock и AccessExclusiveLock, поэтому пока у меня есть 2 идеи:

• Когда объект изменяется, Hibernate / DB должен поднять уровень блокировки, и он терпит неудачу, потому что другой поток уже имеет некоторую блокировку в этой строке. Решение - заблокировать досрочно?
• Иногда транзакции просто слишком медленные (> 1 с), и взаимоблокировка дает ложное срабатывание. Решение - увеличить таймаут?