- лучше рисунок сюда, а не в архиве.
- транзакции атомарны, т.е. не надо в неё одну всё пихать (поиск, просмотр и т.д.).
Старт надо на "Изменение чего-либо".
- задача была в изменении, а у вас " добавление записи"
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

kmawзапихал в транзакцию все, потому что на каждом этапе может обрубиться доступ к БД. Напрмер:

не то.
в транзакции только то, чему надо делать откат.
Как будем откатывать операцию "запрос на поиск?"

надеюсь пользователь у тебя не входит в транзакцию?
:)
______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

kmawзапрос на поиск - это начало транзакции, первая точка с которой она начиналась. для неё откат - это возврат в неё же саму
запрос - это действие. Начало транзакции - это точка на схеме или квадрат, который запоминает все действия для отката (упростим).
Поэтому нельзя несколько действий и фразу begintran пихать в один квадрат.

С транзакциями работает сервис, а не клиент (он только даёт ему команду). У вас сервис ничего не делает, а только 6 копий одного действия "обработка запроса".

kmaw
Веб сервис по требованиям ТЗ работает "безотказно", но ресурсы, к которым он обращается, могут временно быть недоступны.

==== это как? Как он делает запрос к недоступной БД?

Работа оператора должна быть непрерывной, и не зависеть от этих внешних ресурсов. Веб-сервис, следовательно, должен уметь сохранять у себя данные, которые добавляются или обновляются на время отсутствия доступа к внешним БД.

======== это невозможно без рапликации. (безотказная работа с рессурсами, которые недоступны)

Диез kmawможет я не совсем понятно объяснил суть проблемы, но меня интересует не философия по поводу что считать транзакцией, что в неё включать или не включать; технические вопросы по поводу репликации БД и хранилища на сервисе тоже пока не интересуют. Интересует решение вопроса, связанного с тем, как на веб-сервисе организовать временное хранение данных, которые там могут появиться в следующих случаях:
1. клиент дал запрос на поиск, ему вернулся результат, после чего БД недоступна
2. клиен дал запрос на добавление, но в этот момент БД недоступна
3. клиент дал запрос на изменение, но в этот момент БД недоступна

Возможно, этот список не исчерпывающий и требует уточнения, но суть мне кажется (если смотреть на схему взаимодействия) ясна

А скажите, зачем вам нужен BizTalk в вышеприведенной схеме?
делать оркестровку бизнес-процессов. Т.е. загрузит схему выше в word и получит работающую Информ-Систему.
:)

kmaw
проблема в том, что каналы до внешних БД иногда падают, а оператор должен работать, потому что КЛИЕНТЫ, ОЧЕРЕДЬ. И надо оптимизировать работу оператора с одной стороны, чтобы он не ждал, пока появится связь, и с другой стороны минимизировать избыточность, которая неизбежна, если данные хранить на промежуточном слое.
вы читали про "репликацию"? Она как раз решает эту проблему.

kmawОператор 1 дал запрос на посик Петрова А.Д.1977. Бд не работает. Результат поиска отрицательный. Добавляем.
Оператор 2 дал запрос на поиск Иванова А.Д.1977. Бд не работает. Результат поиска отрицательный. Добавляем.

- если два клиента добавляют одно и то-же лицо?
- если 2 клиента правят одно и то же лицо?

При репликации сервер сам не оканчивает транзакцию, пока не восстановится связь и не будут разрешены коллизии и противоречия.

Можно конечно и ручками писать вместо сервера.