Здравствуйте, Shmj, Вы писали:

S>Просто если вручную делать 2 подключения, 2 Commit-а. Если второй Commit не сработал — то первый уже откатить нельзя

С чего бы это?

StartTransaction()
try {
    doSmthInDBMS()
    IncWorkCounter -> общий семафор, счётчик, чё угодно
    WaitUntilCounterEquals2() // здесь ждём с неким таймаутом и выбрасываем иксепшын если не дождались
    CommitTrans()
} catch {
    Rollback()
}

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

Здравствуйте, 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 не сработал — то первый уже откатить нельзя.

Поэтому обычно так стараются не делать, где важно отсутствие рассинхронизации данных в нескольких источниках.
В общем случае задача разделяется на ряд асинхронных (по отношению к друг другу) процессов обеспечивающих синхронизацию на основе очередей.
Например, процесс №1 (до commit-а) отправляет задачу/сообщение на синхронизацию процессу №2 по некоторому ключу, который процесс №1 должен будет у себя также сохранить.
Процесс №2 будет периодически обрабатывать очередь поступивших задач, проверяя наличие ключа (полученного в рамках задачи) в хранилище процесса №1.

Под ключом в данном случае подразумевается просто некий набор байт, однозначно идентифицирующий элемент в очереди на синхронизацию, хранить его можно например в отдельной таблице вида:
[ключ] [дата/время] [что-то еще]

Таким образом, если процессу №1:
— НЕ удалось отправить задачу процессу №2, то commit не произойдет.
— удалось отправить задачу процессу (2), но не удалось выполнить commit, то процесс (2) данные по этому ключу не обнаружит в хранилище процесса №1, и по истечении какого-то времени, должен будет эту задачу отклонить.

Естественно тут важно обеспечивать хронологический порядок обработки элементов очереди.

S> TransactionScope вроде решает эту проблему или тоже не гарантированно?

Для MSSQL и Oracle может и решает, во всяком случае через MSDTC пытается это делать:
https://stackoverflow.com/questions/1690892/transactionscope-automatically-escalating-to-msdtc-on-some-machines

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Kolesiki, Вы писали:

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

S>Тут у вас один общий коммит.

Где ты нашёл "общий коммит"? Бухой что ли? Это дублирующийся код, работающий каждый для своей СУБД.

Мы на практике соединяли несколько MSSQL и ORACLE баз в единые транзакции — всё работает и всё откатывается, если надо.
Я уже давненько не на том проекте, но, как говорится, у истоков стоял.
Это родилось в Porsche Engineering Center как наколенковый проект, а потом разрослось до всег Volks Wagen концерна.
У них все разрозненные базы данных соединяются, виртуально, в единую виртуальную объектную модель.
Здесь и создан свой макро язык запросов, где в рамках одного CRUD запроса могут оказаться связанными несколько разношерстных источников данных — обычно это, упомянутые, MSSQL и ORACLE серверы.
И всё работает!

Здравствуйте, Shmj, Вы писали:


S>Если внутри scope происходят действия в двух разных СБУД, гарантируется ли распределенная транзакция и гарантированный откат? А так же все ли официально поставляемые провайдеры СУБД поддерживают этот функционал?
S>Просто если вручную делать 2 подключения, 2 Commit-а. Если второй Commit не сработал — то первый уже откатить нельзя. TransactionScope вроде решает эту проблему или тоже не гаранрированно?

TransactionScope использует менеджер транзакций MS DTC, который поддерживается только MS SQL Server. Хотя, может я и ошибаюсь.

Сейчас веяния архитектуры, что один сервис в одном процессе и этот сервис использует свою бд.
Т.е. один сервис — одна бд. И все изменения данных в этой бд через API (REST, SOAP, gRPC и пр.).
Я бы задумался, почему один процесс пишет в две разные БД? Попахивает плохой архитектурой.
А для двух процессов TransactionScope не будет работать, и надо использовать паттерн "Сага".

Здравствуйте, Kolesiki, Вы писали:

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

Тут у вас один общий коммит. А если две разные СУБД, в каждой открываете свою транзакцию и нужно 2 коммита? Если первый прошел а второй нет — то что делать?

Здравствуйте, Kolesiki, Вы писали:

K>Где ты нашёл "общий коммит"? Бухой что ли? Это дублирующийся код, работающий каждый для своей СУБД.

Вы дождетесь WaitUntilCounterEquals2() в каждом из дублирующихся кодов. Потом первый коммит отработает и накатит изменения в базе. А второй чего-то зависнет на долго и потом вообще соединение оборвалось — сервер СУБД перезагрузили в этот момент.

В итоге первый коммит прошел — а второй не успел, хотя запустили вы их как бы одновременно.

Здравствуйте, Shmj, Вы писали:

S>Если внутри scope происходят действия в двух разных СБУД, гарантируется ли распределенная транзакция и гарантированный откат? А так же все ли официально поставляемые провайдеры СУБД поддерживают этот функционал?

S>Просто если вручную делать 2 подключения, 2 Commit-а. Если второй Commit не сработал — то первый уже откатить нельзя. TransactionScope вроде решает эту проблему или тоже не гаранрированно?

Распределенные транзакции юзают двухфазный коммит — prepare+commit

Здравствуйте, Shmj, Вы писали:

S>Но эта ситуация — 1 на 100 миллиардов примерно. Если до коммита все работало и база доступна — то сам коммит — это 100 миллисекунд — практически не вероятно что за эти 100 миллисекунд что-то отвалится. Тем более соединения все-таки достаточно надежные.

И чего ты нам голову тогда морочишь? Сам видишь, высасываешь ситуации вообще нереальные и хочешь мира во всём мире — может хватит уже студенческих пи****достраданий?? Делом займись, программу напиши.

Кто может сказать про это:

var scope = new TransactionScope();
...
scope.Complete();

Если внутри scope происходят действия в двух разных СБУД, гарантируется ли распределенная транзакция и гарантированный откат? А так же все ли официально поставляемые провайдеры СУБД поддерживают этот функционал?

Просто если вручную делать 2 подключения, 2 Commit-а. Если второй Commit не сработал — то первый уже откатить нельзя. TransactionScope вроде решает эту проблему или тоже не гаранрированно?

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Распределенные транзакции юзают двухфайзный коммит — prepare+commit

И как это спасает от ситуации:

1. prepare1 — сработал.
2. prepare2 — сработал.
3. commit1 — сработал.
4. commit2 — не сработал (по тем или иным причинам — пусть даже по сетевым).

Что делать на шаге 4? Отменять шаг 3, как я понимаю, уже поздно.

Здравствуйте, Shmj, Вы писали:

S>Что делать на шаге 4? Отменять шаг 3, как я понимаю, уже поздно.
повторить?

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>>Распределенные транзакции юзают двухфайзный коммит — prepare+commit

S>И как это спасает от ситуации:

S>1. prepare1 — сработал.
S>2. prepare2 — сработал.
S>3. commit1 — сработал.
S>4. commit2 — не сработал (по тем или иным причинам — пусть даже по сетевым).

S>Что делать на шаге 4? Отменять шаг 3, как я понимаю, уже поздно.

Генерим ошибку: "Бд не согласованы", пусть админ разбирается. Система-то уже распределенная, тут либо согласованность, либо доступность, но для нас важна именно согласованность.

Здравствуйте, Shmj, Вы писали:

S>И как это спасает от ситуации:

Гарантированно от проблем не спасает вообще ничего, слышал про CAP теорему? Двухфазный коммит всего лишь сильо снижает вероятность. Насколько сильно — зависит от того насколько вероятно конкретный ресурс может сбойнуть после успешного prepare.
Ну и, в целом, идея двухфазного коммита и DTC не особо сейчас популярна, очень тяжеловесно и плохо масштабируется. В таких ситуациях чаще все используют т.н. eventual consistency. В этой модели отказываются от требования consistency в любой произвольный момент времени, за счет чего обходят огранияения САР теоремы.

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>>Распределенные транзакции юзают двухфайзный коммит — prepare+commit

S>И как это спасает от ситуации:

S>1. prepare1 — сработал.
S>2. prepare2 — сработал.
S>3. commit1 — сработал.
S>4. commit2 — не сработал (по тем или иным причинам — пусть даже по сетевым).

S>Что делать на шаге 4? Отменять шаг 3, как я понимаю, уже поздно.

В документации разработчики БД пишут, что мамой клянуться, что закоммитят на 3 и 4, лишь бы электричество было в розетке.

Здравствуйте, B7_Ruslan, Вы писали:

B_R>В документации разработчики БД пишут, что мамой клянуться, что закоммитят на 3 и 4, лишь бы электричество было в розетке.

А если интернет пропал в розетке?

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, B7_Ruslan, Вы писали:

B_R>>В документации разработчики БД пишут, что мамой клянуться, что закоммитят на 3 и 4, лишь бы электричество было в розетке.

S>А если интернет пропал в розетке?

логика сохранения должно позволять безболезненно повторить любую операцию(проверка по GUID).

while (!ReTry()){;}

Здравствуйте, vaa, Вы писали:

vaa>Здравствуйте, Shmj, Вы писали:

S>>Здравствуйте, B7_Ruslan, Вы писали:

B_R>>>В документации разработчики БД пишут, что мамой клянуться, что закоммитят на 3 и 4, лишь бы электричество было в розетке.

S>>А если интернет пропал в розетке?

vaa>логика сохранения должно позволять безболезненно повторить любую операцию(проверка по GUID).
vaa>

vaa>while (!ReTry()){;}
vaa>

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

Здравствуйте, Qulac, Вы писали:

Q>Генерим ошибку: "Бд не согласованы", пусть админ разбирается. Система-то уже распределенная, тут либо согласованность, либо доступность, но для нас важна именно согласованность.

Почему либо-либо? Она может быть и согласованной и доступной, но только на чтение. Запись уже не даем.

Здравствуйте, Qulac, Вы писали:


Q>Это понятно, правда что делать в этом случае клиенту этого апи, когда она делает повторы, ждать? Клиент обычно хочет не позже указанного времени получить либо результат, либо ошибку. Так что в общем случае, проблема все равно ни куда не девается.

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

Здравствуйте, vaa, Вы писали:

vaa>логика сохранения должно позволять безболезненно повторить любую операцию(проверка по GUID).
vaa>

vaa>while (!ReTry()){;}
vaa>

Но первая база "думает" что все ОК, что транзакция завершена. Ее же уже закоммитили. А по факту может быть еще нет, т.е. во второй базе транзакцию не закоммитили.

Здравствуйте, Sharov, Вы писали:

S>Почему либо-либо? Она может быть и согласованной и доступной, но только на чтение. Запись уже не даем.

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

Здравствуйте, vaa, Вы писали:

Q>>Это понятно, правда что делать в этом случае клиенту этого апи, когда она делает повторы, ждать? Клиент обычно хочет не позже указанного времени получить либо результат, либо ошибку. Так что в общем случае, проблема все равно ни куда не девается.

vaa>Это realworld, нужно все апи делать асинхронным, пусть попытка одна но клиент сам повторяет попытки записи или пусть будет два метода, один запускает операцию, второй позволяет чекать результат.
vaa>вообщем проблемы как таковой нет.

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

Здравствуйте, Shmj, Вы писали:

S>Тут проблема в том, что 2 базы не согласованы. В первой коммит прошел — во второй нет. Нужно как-то в первой базе взад блоконуть все данные, которые были изменены в момент комита, чтобы никто их больше не изменял

https://developers.redhat.com/blog/2018/10/01/patterns-for-distributed-transactions-within-a-microservices-architecture#what_is_a_distributed_transaction_

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

Здравствуйте, vaa, Вы писали:

vaa>Здравствуйте, Shmj, Вы писали:

S>>Тут проблема в том, что 2 базы не согласованы. В первой коммит прошел — во второй нет. Нужно как-то в первой базе взад блоконуть все данные, которые были изменены в момент комита, чтобы никто их больше не изменял

vaa>https://developers.redhat.com/blog/2018/10/01/patterns-for-distributed-transactions-within-a-microservices-architecture#what_is_a_distributed_transaction_

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

У нас система класса CA по CAP Теорема CAP т.е. в случае разделения она не может дать корректный отклик за оговоренное в т.з. время. Транзакция либо зависнет в ожидании завершения другой транзакции либо столкнется с одним из не работающих серверов. Самый разумный выход в этом случае — вернуть ошибку.

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Sharov, Вы писали:
S>>Почему либо-либо? Она может быть и согласованной и доступной, но только на чтение. Запись уже не даем.
S>В первой или во второй базе?

По идее в обоих -- вся система становится readonly.

S>Каким образом в первой базе ограничить запись, если уже коммит был?

Без понятия, но думаю это тот случай, когда необходимо ручное вмешательство. И задача инженеров и программистов
это ручное вмешательство минимизировать. Т.е. речь об архитектуре и производительности, что если что-то не так,
то об этом сразу становится известно всем, и система переходит в соотв. режим работы (readonly).

Здравствуйте, Yuri Abele, Вы писали:

YA>Мы на практике соединяли несколько MSSQL и ORACLE баз в единые транзакции — всё работает и всё откатывается, если надо.
YA>Я уже давненько не на том проекте, но, как говорится, у истоков стоял.
YA>Это родилось в Porsche Engineering Center как наколенковый проект, а потом разрослось до всег Volks Wagen концерна.
YA>У них все разрозненные базы данных соединяются, виртуально, в единую виртуальную объектную модель.
YA>Здесь и создан свой макро язык запросов, где в рамках одного CRUD запроса могут оказаться связанными несколько разношерстных источников данных — обычно это, упомянутые, MSSQL и ORACLE серверы.
YA>И всё работает!

Интересно как оно откатывало если один конекшин свалился, а второй закомитил

Здравствуйте, Danchik, Вы писали:

D>Здравствуйте, Yuri Abele, Вы писали:

YA>>Мы на практике соединяли несколько MSSQL и ORACLE баз в единые транзакции — всё работает и всё откатывается, если надо.
YA>>Я уже давненько не на том проекте, но, как говорится, у истоков стоял.
YA>>Это родилось в Porsche Engineering Center как наколенковый проект, а потом разрослось до всег Volks Wagen концерна.
YA>>У них все разрозненные базы данных соединяются, виртуально, в единую виртуальную объектную модель.
YA>>Здесь и создан свой макро язык запросов, где в рамках одного CRUD запроса могут оказаться связанными несколько разношерстных источников данных — обычно это, упомянутые, MSSQL и ORACLE серверы.
YA>>И всё работает!

D>Интересно как оно откатывало если один конекшин свалился, а второй закомитил
Тут надо разобраться, как работают транзакции. Они, на самом деле, не одношаговые операции а двух трёх.
В нашем случае трёх. И каждый из шагов, на каждом из ресурсов должен случиться. Если же где-то "обломился", то, спустя какое-то время, происходит автоматический откат.
За деталями в гугль

Здравствуйте, Yuri Abele, Вы писали:

[Skip]

D>>Интересно как оно откатывало если один конекшин свалился, а второй закомитил
YA>Тут надо разобраться, как работают транзакции. Они, на самом деле, не одношаговые операции а двух трёх.
YA>В нашем случае трёх. И каждый из шагов, на каждом из ресурсов должен случиться. Если же где-то "обломился", то, спустя какое-то время, происходит автоматический откат.
YA>За деталями в гугль

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

Здравствуйте, Danchik, Вы писали:

D>Интересно как оно откатывало если один конекшин свалился, а второй закомитил

Скорее всего никак. Но эта ситуация — 1 на 100 миллиардов примерно. Если до коммита все работало и база доступна — то сам коммит — это 100 миллисекунд — практически не вероятно что за эти 100 миллисекунд что-то отвалится. Тем более соединения все-таки достаточно надежные.

Это только искусственно делать нужно все, устраивать такой тест.

Почти уверен что никак не сможет среагировать.

Ну или такая ситуация — 1 закоммитил, 2 не смог. Пробует 1 раскоммитить — и уже не доступен и 1. Что делать?

Здравствуйте, Shmj, Вы писали:

А что если попробовать мануальный коммит. То есть создать еще третью транзакцию, которая и будет сообщать удались предыдущие две или нет.
Если третья транзакция не удалась, то предыдущие две тоже считаются неудавшимися.

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

S>Кто может сказать про это:

S>

S>var scope = new TransactionScope();
S>...
S>scope.Complete();
S>

S>Если внутри scope происходят действия в двух разных СБУД, гарантируется ли распределенная транзакция и гарантированный откат? А так же все ли официально поставляемые провайдеры СУБД поддерживают этот функционал?

S>Просто если вручную делать 2 подключения, 2 Commit-а. Если второй Commit не сработал — то первый уже откатить нельзя. TransactionScope вроде решает эту проблему или тоже не гаранрированно?

Здравствуйте, Shmj, Вы писали:

S>Ну или такая ситуация — 1 закоммитил, 2 не смог. Пробует 1 раскоммитить — и уже не доступен и 1. Что делать?

Поствалидация или ручное вмешательство.

Здравствуйте, Shmj, Вы писали:

S>И как это спасает от ситуации:

S>1. prepare1 — сработал.
S>2. prepare2 — сработал.
S>3. commit1 — сработал.
S>4. commit2 — не сработал (по тем или иным причинам — пусть даже по сетевым).

S>Что делать на шаге 4? Отменять шаг 3, как я понимаю, уже поздно.
Не совсем. В таких случаях делают компенсирующую транзакцию для шага 3.

Здравствуйте, IB, Вы писали:

S>>Что делать на шаге 4? Отменять шаг 3, как я понимаю, уже поздно.
IB>Не совсем. В таких случаях делают компенсирующую транзакцию для шага 3.

А если уже поздно? Транзакция то уже была закоммичена в рамках базы 1 и никто не ждал, что ее можно компенсировать. Денежки тю-тю.

Или оставлять некое время в блокированном состоянии после коммита, в которое ждем возможным компенсацию? Какое время ждать?

Здравствуйте, Shmj, Вы писали:

S>Или оставлять некое время в блокированном состоянии после коммита, в которое ждем возможным компенсацию? Какое время ждать?
по формуле: время ожидания = на каждый цент по 1 секунде.