frozer, в данном случае разбивают длинную (бизнес) транзакцию на несколько маленьких (системных) транзакций.
Чтобы данные между системными транзакциями не потеряли актуальность применяют автономную блокировку (АБ).
Различают оптимистическую и пессимистическую АБ.
Оптимистическая:
Условия применения: вероятность конфликта мала (либо длинна бизнес-транзакции мала, либо данные врятли понадобятся кому-то еще).
Реализация: перед выполнением очередной системной транзакции проверяется не изменились ли данные другой транзакцией. Если изменились транзакция завершается и юзеру выкидывается ошибка с просьбой начать сначала.
Для определения изменились ли данные к объекту в базе данных добавляют новое поле: время последнего изменения либо версию объекта (увеличивается после каждого изменения).
Пессимистическая:
Условия применения: вероятность конфликта высока (либо длинна бизнес-транзакции велика, либо высокая конкуренция на доступ).
Реализация: В начале бизнес транцакции данные ей необходимо заблокировать (для этого, например, используют специальную таблицу блокировок). В конце транзакции блокировку снимают.
Реализация оптиместической блокаровки проста и не требует много знаний и внимания, пессимистическая же требует и того и другого. Поэтому в большинстве случаев рекомендуют использовать первую, и только в крайних случаях вторую.
Существует еще и смешанная блокировка: оптимистическая на чтение и пессимистическая на запись. |
)
, может entityspaces подойдет - буду разбираться.