Здравствуйте, Poul_Ko, Вы писали:

P_K>У клиента одно действие — создать новый неподтверждённый заказ. Этот заказ создаётся и болтается в системе пока его не подтвердят или не отменят. И пока он болтается неподтверждённый цена в нём всегда должна строго соответствовать цене из справочника.
P_K>Вполне допустимо, что перед созданием нового неподтверждённого заказа на экране юзер видел одну цену, а после создания она стала другой.

Я бы, на месте клиента, такой юмор не оценил. Это уже вопрос к аналитикам, которые не понимают то ли чего им надо, то ли как функционирует ПО. Если цена в неподтвержденном заказе должна всегда браться из справочника — так и берите ее всегда из справочника, а не храните в заказе. Проблема решена)

Одно из самых простых решений проблемы рассогласованности в системе — не дублировать данные. И кешировать при необходимости, но кешировать явно, с управлением времени жизни и возможностью инвалидации при необходимости.

Что касается исходного вопроса, помимо укрупнения локов, что уже посоветовали, можно лочить более избирательно. В примере с кинотеатром, serializable не так уж страшен, если ограничить его строками для конкретного зала. Или вообще завести отдельную таблицу специально под локи и захватывать их руками в хранимке.