Когда имеет смысл иметь одну транзакцию на несколько соединений с базой данных?

Question

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

Answer 1

Если вы имеете в виду, что несколько баз данных обновляются в рамках одной транзакции, то вы сделаете это для атомарности - http://en.wikipedia.org/wiki/Atomicity_(database_systems)

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

Транзакция означает, что сбой в одном из обновлений означает, что все они отменены (отменены), чтобы оставить данные в состоянии, в котором они находились до начала транзакции.

Answer 2

Лично я не нахожу это разумным в СУРБД - однако я вижу, что это уменьшает сложность проектирования для ОЧЕНЬ высоконагруженных баз данных.

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

но на 99% есть лучшая альтернатива, которую можно решить в дизайне.

- редактировать: подводные камни глобальных транзакций -

Эти 2 пункта, поэтому я бы порекомендовал не использовать глобальные транзакции

Точка 1:

Глобальные транзакции включают несколько серверов баз данных (или, по крайней мере, они должны) - глобальная транзакция требует DTC (координатор распределенных транзакций) - использование такого агента снизит скорость ваших запросов на ЗАКАЗЫ факторов, так как не делаются в рамках одной машины, но задействуют несколько машин, что означает сеть.

Точка 2:

Если ваши запросы не разработаны должным образом (большинство людей не понимают тонкостей), вы можете блокировать большие части таблиц в отдельных базах данных, а иногда даже блокировать целые таблицы одним запросом. Если вещи не будут должным образом спроектированы для распределенных запросов, ваши приложения остановятся и кто-то будет уволен: D. Вам нужно убедиться, что ваши запросы в итоге блокируют только то, что они должны, и вы должны убедиться, что эти заблокированные части данных одновременно используются только одним запросом.

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

- редактировать: потенциальная область, которую вы можете исследовать -

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

Answer 3

Когда вы хотите транзакционную операцию, которая влияет на несколько баз данных.