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

S>И худший он именно из-за того, что быстрое звено (СУБД) вынуждено удерживать блокировки до тех пор, пока медленное звено (веб-сервис) не проснется и не ответит.
S>Более того, в предлагаемой схеме временная проблема с веб-сервисом (банальное падение роутера между ним и application tier) иожет привести к откату транзакции резервирования товара. Так делать не надо.

S>Правильный способ, конечно же, в том, чтобы сделать у заказа дополнительное состояние — "передан на упаковку", куда можно перейти только если заказ "зарезервирован".

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

S>А теперь расскажи нам, как это работает в случае unit of work. Какие блокировки накладываются в какой момент, и в какой они отпускаются. Учти еще, что характерное время ответа от веб-сервиса — это 200мс, а одиночный апдейт в базе выполнится примерно за 10мс.

Я про фому, а ты опять про ерему. В реальной жизни ты не добьешься непересечения под-задач по данным. Хотя бы уже потому, что иначе тебе при каждом изменении нужно будет просматривать все использования изменяемого тобою кода. А с учетом того, что предполагается использовать возможности БД на полную катушку, это еще более усложняется.