var scope = new TransactionScope();
...
scope.Complete();
Если внутри scope происходят действия в двух разных СБУД, гарантируется ли распределенная транзакция и гарантированный откат? А так же все ли официально поставляемые провайдеры СУБД поддерживают этот функционал?
Просто если вручную делать 2 подключения, 2 Commit-а. Если второй Commit не сработал — то первый уже откатить нельзя. TransactionScope вроде решает эту проблему или тоже не гаранрированно?
Здравствуйте, Shmj, Вы писали:
S>Кто может сказать про это:
S>
S>var scope = new TransactionScope();
S>...
S>scope.Complete();
S>
S>Если внутри scope происходят действия в двух разных СБУД, гарантируется ли распределенная транзакция и гарантированный откат? А так же все ли официально поставляемые провайдеры СУБД поддерживают этот функционал?
S>Просто если вручную делать 2 подключения, 2 Commit-а. Если второй Commit не сработал — то первый уже откатить нельзя. TransactionScope вроде решает эту проблему или тоже не гаранрированно?
2 базы MS SQL могут так работать, если настроить MSDTC.
2 Postgres вроде смогут работать, но там координатора нет, со всеми вытекающими.
2 Oracle с купленным координатором в теории должны.
Но 2 разные СУБД завести — мне кажется, это фантастика.
Даже, если сможете запустить это — будет невысокая производительность.
Нельзя просто так взять и во все места засунуть 2PC-транзакции.
Здравствуйте, Shmj, Вы писали:
S>Просто если вручную делать 2 подключения, 2 Commit-а. Если второй Commit не сработал — то первый уже откатить нельзя
С чего бы это?
StartTransaction()
try {
doSmthInDBMS()
IncWorkCounter -> общий семафор, счётчик, чё угодно
WaitUntilCounterEquals2() // здесь ждём с неким таймаутом и выбрасываем иксепшын если не дождались
CommitTrans()
} catch {
Rollback()
}
Два таких куска кода делают работу и коммитят только если оба успешны.
Набросал сходу, но можно придумать что-то и без таймаутов.
Re[2]: Про распределенные транзакции и разные СУБД
Здравствуйте, Kolesiki, Вы писали:
K>Два таких куска кода делают работу и коммитят только если оба успешны. K>Набросал сходу, но можно придумать что-то и без таймаутов.
Тут у вас один общий коммит. А если две разные СУБД, в каждой открываете свою транзакцию и нужно 2 коммита? Если первый прошел а второй нет — то что делать?
Re[3]: Про распределенные транзакции и разные СУБД
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Kolesiki, Вы писали:
K>>Два таких куска кода делают работу и коммитят только если оба успешны. K>>Набросал сходу, но можно придумать что-то и без таймаутов.
S>Тут у вас один общий коммит.
Где ты нашёл "общий коммит"? Бухой что ли? Это дублирующийся код, работающий каждый для своей СУБД.
Re[4]: Про распределенные транзакции и разные СУБД
Здравствуйте, Kolesiki, Вы писали:
K>Где ты нашёл "общий коммит"? Бухой что ли? Это дублирующийся код, работающий каждый для своей СУБД.
Вы дождетесь WaitUntilCounterEquals2() в каждом из дублирующихся кодов. Потом первый коммит отработает и накатит изменения в базе. А второй чего-то зависнет на долго и потом вообще соединение оборвалось — сервер СУБД перезагрузили в этот момент.
В итоге первый коммит прошел — а второй не успел, хотя запустили вы их как бы одновременно.
Здравствуйте, Shmj, Вы писали:
S>Просто если вручную делать 2 подключения, 2 Commit-а. Если второй Commit не сработал — то первый уже откатить нельзя.
Поэтому обычно так стараются не делать, где важно отсутствие рассинхронизации данных в нескольких источниках.
В общем случае задача разделяется на ряд асинхронных (по отношению к друг другу) процессов обеспечивающих синхронизацию на основе очередей.
Например, процесс №1 (до commit-а) отправляет задачу/сообщение на синхронизацию процессу №2 по некоторому ключу, который процесс №1 должен будет у себя также сохранить.
Процесс №2 будет периодически обрабатывать очередь поступивших задач, проверяя наличие ключа (полученного в рамках задачи) в хранилище процесса №1.
Под ключом в данном случае подразумевается просто некий набор байт, однозначно идентифицирующий элемент в очереди на синхронизацию, хранить его можно например в отдельной таблице вида:
[ключ] [дата/время] [что-то еще]
Таким образом, если процессу №1:
— НЕ удалось отправить задачу процессу №2, то commit не произойдет.
— удалось отправить задачу процессу (2), но не удалось выполнить commit, то процесс (2) данные по этому ключу не обнаружит в хранилище процесса №1, и по истечении какого-то времени, должен будет эту задачу отклонить.
Естественно тут важно обеспечивать хронологический порядок обработки элементов очереди.
S> TransactionScope вроде решает эту проблему или тоже не гарантированно?
Здравствуйте, Shmj, Вы писали:
S>Если внутри scope происходят действия в двух разных СБУД, гарантируется ли распределенная транзакция и гарантированный откат? А так же все ли официально поставляемые провайдеры СУБД поддерживают этот функционал?
S>Просто если вручную делать 2 подключения, 2 Commit-а. Если второй Commit не сработал — то первый уже откатить нельзя. TransactionScope вроде решает эту проблему или тоже не гаранрированно?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>>Распределенные транзакции юзают двухфайзный коммит — prepare+commit
S>И как это спасает от ситуации:
S>1. prepare1 — сработал. S>2. prepare2 — сработал. S>3. commit1 — сработал. S>4. commit2 — не сработал (по тем или иным причинам — пусть даже по сетевым).
S>Что делать на шаге 4? Отменять шаг 3, как я понимаю, уже поздно.
Генерим ошибку: "Бд не согласованы", пусть админ разбирается. Система-то уже распределенная, тут либо согласованность, либо доступность, но для нас важна именно согласованность.
Программа – это мысли спрессованные в код
Re[3]: Про распределенные транзакции и разные СУБД
Здравствуйте, Shmj, Вы писали:
S>И как это спасает от ситуации:
Гарантированно от проблем не спасает вообще ничего, слышал про CAP теорему? Двухфазный коммит всего лишь сильо снижает вероятность. Насколько сильно — зависит от того насколько вероятно конкретный ресурс может сбойнуть после успешного prepare.
Ну и, в целом, идея двухфазного коммита и DTC не особо сейчас популярна, очень тяжеловесно и плохо масштабируется. В таких ситуациях чаще все используют т.н. eventual consistency. В этой модели отказываются от требования consistency в любой произвольный момент времени, за счет чего обходят огранияения САР теоремы.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[3]: Про распределенные транзакции и разные СУБД
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>>Распределенные транзакции юзают двухфайзный коммит — prepare+commit
S>И как это спасает от ситуации:
S>1. prepare1 — сработал. S>2. prepare2 — сработал. S>3. commit1 — сработал. S>4. commit2 — не сработал (по тем или иным причинам — пусть даже по сетевым).
S>Что делать на шаге 4? Отменять шаг 3, как я понимаю, уже поздно.
В документации разработчики БД пишут, что мамой клянуться, что закоммитят на 3 и 4, лишь бы электричество было в розетке.
Re[4]: Про распределенные транзакции и разные СУБД
Здравствуйте, B7_Ruslan, Вы писали:
B_R>В документации разработчики БД пишут, что мамой клянуться, что закоммитят на 3 и 4, лишь бы электричество было в розетке.
А если интернет пропал в розетке?
Re[5]: Про распределенные транзакции и разные СУБД
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, B7_Ruslan, Вы писали:
B_R>>В документации разработчики БД пишут, что мамой клянуться, что закоммитят на 3 и 4, лишь бы электричество было в розетке.
S>А если интернет пропал в розетке?
логика сохранения должно позволять безболезненно повторить любую операцию(проверка по GUID).
while (!ReTry()){;}
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[6]: Про распределенные транзакции и разные СУБД
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, Shmj, Вы писали:
S>>Здравствуйте, B7_Ruslan, Вы писали:
B_R>>>В документации разработчики БД пишут, что мамой клянуться, что закоммитят на 3 и 4, лишь бы электричество было в розетке.
S>>А если интернет пропал в розетке?
vaa>логика сохранения должно позволять безболезненно повторить любую операцию(проверка по GUID). vaa>
vaa>while (!ReTry()){;}
vaa>
Это понятно, правда что делать в этом случае клиенту этого апи, когда она делает повторы, ждать? Клиент обычно хочет не позже указанного времени получить либо результат, либо ошибку. Так что в общем случае, проблема все равно ни куда не девается.
Здравствуйте, Qulac, Вы писали:
Q>Генерим ошибку: "Бд не согласованы", пусть админ разбирается. Система-то уже распределенная, тут либо согласованность, либо доступность, но для нас важна именно согласованность.
Почему либо-либо? Она может быть и согласованной и доступной, но только на чтение. Запись уже не даем.
Кодом людям нужно помогать!
Re[7]: Про распределенные транзакции и разные СУБД
Q>Это понятно, правда что делать в этом случае клиенту этого апи, когда она делает повторы, ждать? Клиент обычно хочет не позже указанного времени получить либо результат, либо ошибку. Так что в общем случае, проблема все равно ни куда не девается.
Это realworld, нужно все апи делать асинхронным, пусть попытка одна но клиент сам повторяет попытки записи или пусть будет два метода, один запускает операцию, второй позволяет чекать результат.
вообщем проблемы как таковой нет.
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[6]: Про распределенные транзакции и разные СУБД
Здравствуйте, vaa, Вы писали:
vaa>логика сохранения должно позволять безболезненно повторить любую операцию(проверка по GUID). vaa>
vaa>while (!ReTry()){;}
vaa>
Но первая база "думает" что все ОК, что транзакция завершена. Ее же уже закоммитили. А по факту может быть еще нет, т.е. во второй базе транзакцию не закоммитили.
