Возможна ли транзакция между веб-службой и базой данных?

Я хочу вызвать веб-службу, чтобы вставить запись в ее базу данных, а затем я хочу вставить запись в удаленную базу данных в другом городе, если веб-служба успешно выполнит операцию.

вот упрощенный пример кода:

IdentificationSystem.Service Identify = new IdentificationSystem.Service();
        string result= Identify.InsertWorkshopInfo(BosWorkshop.WpSvUserName, BosWorkshop.WpSvPassword,BosWorkshop.WkIcode,BosWorkshop.WpName)

if (result==0)//If success
 {
   Connect to a remote database and then insert a record 
}

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

Что я должен делать? Могу ли я использовать System.transaction name space здесь? Я сам пишу код веб-сервиса.


c# asp.net web-services
person Raymond Morphy    schedule 10.07.2011    source источник
comment
вы можете использовать System.transaction, потому что он может обрабатывать распределенные транзакции   -  person Jayantha Lal Sirisena    schedule 10.07.2011

Ответы (2)


arrow_upward
4
arrow_downward

Если на обоих серверах работает координатор распределенных транзакций (MSDTC), то да, распределенная транзакция возможна.

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

НО, вы должны учитывать последствия: длительная транзакция между серверами, вероятно, нежелательна. Кроме того, есть соображения безопасности и брандмауэра.

person Mitch Wheat    schedule 10.07.2011
comment
Вы имеете в виду запуск службы координатора распределенных транзакций в службах Windows для обоих компьютеров? Или я должен сделать что-то еще? - person Raymond Morphy; 10.07.2011
comment
см. этот пост для проблем: forums.asp.net/ т/1203072.aspx/ - person Mitch Wheat; 10.07.2011
comment
В целом веб-сервисы могут быть реализованы в произвольных технологиях, которые могут ничего не знать о MS DTC. - person djna; 10.07.2011
comment
@Mitch Wheat, пожалуйста, дайте мне ваше предложение - person Raymond Morphy; 11.07.2011
comment
@raymond-morphy: не уверен, что спрашиваешь? - person Mitch Wheat; 11.07.2011
comment
Пожалуйста, обратитесь к этой транзакции - person Raymond Morphy; 11.07.2011
comment
@ Митч, какая у тебя идея? Пожалуйста, дайте мне ваше предложение - person Raymond Morphy; 11.07.2011

arrow_upward
1
arrow_downward

Существуют стандарты WS для работы с распределенными транзакциями см. этот документ, но их использование требует, чтобы авторы веб-службы предлагали интерфейсы, соответствующие этим более продвинутым спецификациям. Это значительно усложняет реализацию и администрирование веб-сервисов, поэтому немногие поставщики услуг предпочитают это делать.

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

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

  • Каждая служба, которую вы используете, должна иметь возможность отмены. Некоторые услуги (например, отправить электронное письмо) естественно не имеют отмены. Другие имеют финансовые затраты на отмену (например, отмена бронирования может потребовать внесения депозита). Хуже того, некоторые авторы сервисов не предоставляют возможности отмены.
  • Вы не всегда знаете, было ли действие действительно завершено. Вы отправляете запрос, затем происходит сбой и, следовательно, вы не видите ответа. Теперь вы пытаетесь повторить попытку и рискуете сделать (скажем) двойной дебет? В идеале автор сервиса предоставляет идемпотентные сервисы (сервисы, которые могут безопасно обрабатывать повторяющиеся запросы на одно и то же действие) и/или некоторые возможности запросов, которые позволяют узнать судьбу запроса.

Моя общая мысль заключается в том, что вы зависите от своих поставщиков услуг в предоставлении вам услуг, которые позволяют вам «составлять» желаемую функциональность множественного обновления. Если вам очень не повезло, то, что вы хотите сделать, может оказаться невозможным. Затем вы возвращаетесь к ручной коррекции для некоторых сценариев сбоя. Реальные компании на самом деле делают многое из этого. Люди звонят по телефону, чтобы выяснить, что произошло, скорректировать заказы и даже попросить их отменить. Если вероятность отказа мала, то это может быть более рентабельным подходом, чем разработка пуленепробиваемой системы.

person djna    schedule 10.07.2011