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

P_K>·>SQL выпоняет такой update атомарно. Твоя цель — свести большие сложные бизнес-операции, котоыре должны выполниться атомарно к элементарной атомарной sql-операции.
P_K>Не могу представить как это будет в реализации.
P_K>Ну вот подтверждаем мы заказ. Открыли транзакцию, прочитали договор, проверили — всё ок. Как теперь проверить что версия не изменилась? Вычитать договор из базы опять? Версия будет та же, если меняющая транзакция ещё не закоммитилась, она же идёт параллельно. И кто гарантирует что после такой проверки но перед коммитом никто не изменит договор?
Ну объяснил же уже вроде. Не просто проверка, а условная атомарная операция. Псевдокод:

SELECT Version, startDate...etc FROM Agreement WHERE id=1;
var CurrentVersion = Version;
// проверяем... долго и упорно
checkIt(startDate);
...
checkIt(etc);

// фиксируем
UPDATE Agreement SET Confirmed='YES' WHERE id=1 AND Version=CurrentVersion;
if(updatedRecords==0) rollback;// упс - облом, придётся начать сначала.

Ну и модифицирующие операции (все или как минимум те, которые могут влиять на проверки) должны изменять версию:

UPDATE Agreement SET startDate = 'yesterday', Version = Version+1 WHERE id = 1

ACID-ность UPDATE обеспечивается sql-сервером.

P_K>Ну и когда я слышу "свести сложные бизнес-операции к элементарной sql-операции" что-то внутри меня переворачивается Бизнес-код должен решать бизнес-задачи, а не подстраиваться под возможности SQL.
Я имел в виду обеспечить атомарность сложной бизнес-операции через атомарные sql-операции. Да, блокировка — способ обеспечения атомарности. Но не единственный.