Служба WCF записывает журнал, только если клиент получает результаты

Question

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

1. Клиент вызывает сервис с запросом на устаревшую систему.
2. Сервис записывает запрос в базу данных.
3. Устаревшие системные сервисы запрашивают у БД в свое время и записывают результаты обратно в БД (обновляя флаг состояния, чтобы сказать результаты готовы ).
4. Клиент получает результаты, вызывая второй сервисный метод, который опрашивает БД, пока не будет установлен флаг готовности.
5. Непосредственно перед возвратом результатов служба обновляет флаг состояния на у клиента есть результаты , так что связанные строки БД могут быть удалены.

Меня беспокоит состояние гонки на последнем этапе. Я вижу, как это происходит:

1. Состояние обновления службы до у клиента есть результаты .
2. Время ожидания клиента истекло после ожидания запроса службы в БД.
3. Служба пытается вернуть результаты. Веселье наступает.

Одним из способов решения этой проблемы было бы использование трех вызовов службы вместо двух: второй вызов извлекает результаты, а последний - явное подтверждение клиентом того, что они есть. Хотелось бы знать, есть ли способ, который не налагает на клиента эту дополнительную «протокольную» нагрузку.

Я кратко рассмотрел использование транзакций в WCF, и похоже, что они могут делать то, что мне нужно. Клиент (опционально) запускает транзакцию, передает ее в службу, которая использует ее, если она там есть, и фиксирует ее по завершении. Кажется, что это неявно делает "третий вызов".

Есть ли у этой идеи какие-либо достоинства? Какие недостатки вы можете увидеть? Есть ли другие пути, которые я мог бы изучить?

Answer 1

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

Использование обработки транзакций накладывает некоторые дополнительные требования на вашу службу и клиентов.

Другим подходом может быть транзакция MSMQ:

1. Клиент вызывает службу с запросом на устаревшую систему = клиент отправляет сообщение в очередь службы
2. Служба записывает запрос в базу данных = служба обрабатывает сообщение из своей очереди
3. Устаревшие системные службы запрашивают у БД в свое время и записывают результаты обратно в БД (обновляя флаг состояния, чтобы сообщить, что результаты готовы).
4. Служба опрашивает базу данных и помещает сообщения для исправления клиентаочереди.Размещение сообщения и изменение записей базы данных выполняется в транзакции
5. Клиент обрабатывает входящее сообщение

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

InВ обоих случаях вы должны думать о клиентах, которые будут пользоваться услугами.Поток транзакций может быть совместимым, но не каждый стек веб-сервисов поддерживает его.MSMQ не совместим.

Answer 2

Почему бы не уменьшить вероятность тайм-аута клиента, сделав это вместо этого:

1. Клиент вызывает службу с запросом на устаревшую систему.
2. Служба записывает запрос вбаза данных.
3. Унаследованные системные службы запрашивают у БД свое время и записывают результаты обратно в БД (обновляя флаг состояния, чтобы сообщить, что результаты готовы).
4. Клиент вызывает службу для поискавне ли результаты готовы.NB.нет опроса: просто возвращается с немедленным да или нет.
5. Если результаты НЕ готовы, клиент немного ждет, а затем возвращается к шагу 4.
6. Если результаты готовы, позвоните в службу, чтобы получить результаты.Служба может обновить статус до «У клиента есть результаты» в этот момент.

Таким образом, клиент не будет ждать вызова службы на шаге 4. для возврата в течение длительного периода, и шансы на тайм-аут должны быть минимальными.

Однако вы никогда не будете на 100% уверены в том, что клиент получил результаты, если только клиент не сделает последний сервисный звонок, чтобы сказать это.(Что если, например, клиент умрет после выполнения самого последнего запроса?)