Здравствуйте, 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).

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

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

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


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

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

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

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

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

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

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