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

P_K>// Почему здесь Agreement? Подтверждаем-то мы заказ!
Эээ.. Да я запутался в твоей модели данных. Но какая разница-то? Суть та же. Версию менять и проверять надо у того, что зависит от изменения данных:

BEGIN TRANS;
UPDATE Agreement SET startDate = ... WHERE id=1;
UPDATE Order SET version=version+1 WHERE agreementId=1;// заметь, тут несколько ордеров может быть изменено.
COMMIT;

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

SELECT version, ... FROM Order...;
var currentVersion = version;
//check
//check
SELECT startDate, ... FROM Agreement...;
//check
//...sloooow check....
//check
UPDATE Order SET confirmed='YES' WHERE version=currentVersion...

А этот процесс не обязательно должен быть в одной транзакции — каждая sql-команда может выполняться сама по себе — транзакции будут короткоживущими, что есть хорошо.

P_K>·>Ну и модифицирующие операции (все или как минимум те, которые могут влиять на проверки) должны изменять версию:
P_K>Это классика оптимистической блокировки, но работает она в пределах одного агрегата, а у нас здесь два (в реальности конечно больше)...
Так оно обобщается до произвольного числа агрегатов.

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

P_K>// Почему здесь Agreement? Подтверждаем-то мы заказ!
Эээ.. Да я запутался в твоей модели данных. Но какая разница-то? Суть та же. Версию менять и проверять надо у того, что зависит от изменения данных:

BEGIN TRANS;
UPDATE Agreement SET startDate = ... WHERE id=1;
UPDATE Order SET version=version+1 WHERE agreementId=1;// заметь, тут несколько ордеров может быть изменено.
COMMIT;

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

SELECT version, ... FROM Order...;
var currentVersion = version;
//check
//check
SELECT startDate, ... FROM Agreement...;
//check
//...sloooow check....
//check
UPDATE Order SET confirmed='YES' WHERE version=currentVersion...

А этот процесс не обязательно должен быть в одной транзакции — каждая sql-команда может выполняться сама по себе — транзакции будут короткоживущими, что есть хорошо.

P_K>·>Ну и модифицирующие операции (все или как минимум те, которые могут влиять на проверки) должны изменять версию:
P_K>Это классика оптимистической блокировки, но работает она в пределах одного агрегата, а у нас здесь два (в реальности конечно больше)...
Так оно обобщается до произвольного числа агрегатов.
Можно даже версировать несколько сущностей, а потом атомарной операцией (т.е. обернутой в транзакцию) делать проверку совпадения всех версий и SET confirmed='YES' если всё совпало.