Смешивание систем возможной согласованности и устаревших систем ACID

Существуют ли какие-либо шаблоны для смешивания систем конечной согласованности с устаревшими системами ACID?

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

У меня есть диспетчер транзакций, который может обрабатывать XA-транзакции с мейнфреймом-tm и реляционной базой данных с поддержкой ACID в среде, отличной от мэйнфрейма (давайте назовем ее NewWorld). Но я не хочу использовать XA-транзакцию, потому что она часто вызывает проблемы с длительными блокировками на стороне мейнфрейма, и во многих случаях мне не нужны все ACID-функции для обоих миров. Мне всегда нужен согласованный мэйнфрейм (все данные в Старом мире согласуются внутри Старого мира). Система NewWorld может обрабатывать несогласованные данные (несогласованность между новыми и старыми), когда она считывает данные со стороны мэйнфрейма. Операции, которые используются для хранения данных в OldWorld, просты и сохраняют «операции только для добавления», которые не могут выйти из строя функционально (могут выйти из строя технически, но это всегда должен быть временный сбой).


locking distributed-transactions eventual-consistency acid lock-free
person Sebastian    schedule 19.02.2013    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Моя идея обойти потребность в распределенной транзакции заключается в том, что я обновляю данные в OldWorld асинхронно и использую уровень данных источника событий (в NewWorlds) для хранения информации о том, что необходимо сделать в OldWorld, используя «мягкую -transaction-id's, чтобы предотвратить двойную отправку в OldWorld. Эти «программные идентификаторы транзакций» будут генерироваться при сохранении данных на уровне данных источника событий для транзакции, которую необходимо выполнить в Старом Свете.

У меня нет изменений, чтобы добавить мой «идентификатор мягкой транзакции» в базы данных OldWorld, но я могу добавить новую базу данных, которая может хранить состояние «Готово» рядом с «идентификатором мягкой транзакции» и сделать обновление этой части базы данных транзакций старого мира. Затем другой асинхронный процесс может прочитать информацию о состоянии без какой-либо блокировки и обновить NewWorld (например, обновить реляционную модель данными из хранилища источников событий. И пометить идентификатор мягкой транзакции как выполненный («глобально-согласованный») ) Обновление OldWorld всегда будет проверять, всегда ли первым фиксируется soft-transaction-id.

Когда я читаю свои записи, у меня возникает ощущение, что это похоже на глобальную транзакцию, только с меньшим количеством блокировок. Знание того, что мое обновление OldWorld будет работать успешно, очень важно, без этого вам нужен процесс слияния вручную, который может справиться с функциональными конфликтами. Системам NewWorld нужна функциональность для обработки несогласованного глобального состояния. Это можно сделать, читая реляционную базу данных и имитируя OldSystem DataRequests, анализируя еще не зафиксированное (в OldWorld-Database) хранилище событий. Для всех других транзакций мне нужно использовать распределенные транзакции с их блокирующим поведением.

person Sebastian    schedule 19.02.2013