У меня нет ответов на эти вопросы, но я создал специальный метод для своего конкретного случая. Поэтому публикуйте здесь, если кому-то нужны транзакции для тех же случаев.
Поскольку в моем случае текущие записи в базе данных (или индексаторе, который также работает как служба) не изменились, а были только новые записи в системе в разных местах, поэтому ложные сбои не были вредными, а ложные успехи были. Итак, для моего конкретного случая я следовал следующей стратегии:
я. Все ресурсы добавляют идентификатор транзакции со строкой в базе данных. На первом этапе, когда координатор запрашивает ресурсы, все ресурсы вносят записи в базу данных с идентификатором транзакции, сгенерированным координатором.
II. После фазы 1, когда все ресурсы отвечают утвердительно, что означает, что ресурсы внесли изменения в базу данных, координатор делает запись в своем собственном журнале об успешной транзакции и передает ее ресурсам. Все ресурсы делают статус транзакции успешным в строке вставленных данных.
III. Служба работает непрерывно для поиска в базе данных и исправления статуса транзакции, запрашивая статус у координатора. Если нет записи или записи об ошибке, транзакция возвращает статус ошибки, и он обновляется в службе. При выборке данных, если в базе данных есть запись с меткой сбоя, он всегда проверяет статус транзакции с координатором, если нет записи об ошибке, он фильтрует результаты. Следовательно, не предоставляются те записи данных, для которых нет информации или имеется информация об отказе. Так что результат всегда одинаков.
Эта стратегия обеспечивает атомарность для моего случая.
person
Vickey
schedule
09.07.2012
