Каковы проблемы использования транзакций в базе данных?
От эта почта. Одна очевидная проблема - масштабируемость / производительность. Какие еще проблемы могут вызвать транзакции?
Могли бы вы сказать, что существует два набора проблем: один для длительно выполняющихся транзакций, а другой - для краткосрочных? Если да, как бы вы их определили?
Обновлено: тупик - еще одна проблема, но несогласованность данных может быть хуже, в зависимости от домена приложения. Если предположить, что домен подходит для транзакций (банковское дело, если использовать канонический пример), возможность тупика больше похожа на плату за обеспечение согласованности данных, чем на проблему с использованием транзакций, иначе вы не согласны? Если да, то какие еще решения вы бы использовали для обеспечения согласованности данных без тупиковых ситуаций?
Ответы 4
Одна из проблем с транзакциями заключается в том, что возможно (маловероятно, но возможно) получить тупиковые ситуации в БД. Вы должны понимать, как работает ваша база данных, как работают блокировки, транзакции и т. д., Чтобы отлаживать эти интересные / разочаровывающие проблемы.
-Адам
Думаю, основная проблема - на уровне дизайна. На каком уровне или уровнях в моем приложении я использую транзакции.
Например, я мог:
- Создавать транзакции в хранимых процедурах,
- Используйте API доступа к данным (ADO.NET) для управления транзакциями
- Используйте некоторую форму неявного отката выше в приложении
- Распределенная транзакция в (через DTC / COM +).
Использование более одного из этих уровней в одном приложении часто создает проблемы с производительностью и / или целостностью данных.
Вы можете получить тупиковые ситуации даже без использования явных транзакций. Во-первых, большинство реляционных баз данных будут применять неявную транзакцию к каждому выполняемому вами оператору.
Взаимоблокировки в основном возникают из-за получения нескольких блокировок, и любое действие, которое включает в себя получение более одной блокировки, может заблокироваться с любым другим действием, которое включает в себя получение как минимум двух таких же блокировок, что и первое действие. В транзакции базы данных некоторые из полученных блокировок могут удерживаться дольше, чем они могли бы удерживаться в противном случае - фактически до конца транзакции. Чем дольше удерживаются блокировки, тем больше вероятность тупиковой ситуации. Вот почему более длительная транзакция имеет больше шансов зайти в тупик, чем более короткая.
Это во многом зависит от реализации транзакции в вашей базе данных, а также может зависеть от уровня изоляции транзакции, который вы используете. Я предполагаю, что здесь "повторяемое чтение" или выше. Сохранение открытых транзакций в течение длительного времени (даже тех, которые ничего не изменили) заставляет базу данных удерживать удаленные или обновленные строки часто изменяющихся таблиц (на случай, если вы решите их прочитать), которые в противном случае могли бы быть выброшены.
Кроме того, откат транзакций может быть очень дорогостоящим. Я знаю, что в движке MySQL InnoDB откат большой транзакции может занять намного больше времени, чем ее фиксация (мы видели, что откат занимал 30 минут).
Другая проблема связана с состоянием подключения к базе данных. В распределенном отказоустойчивом приложении вы никогда не сможете точно узнать, в каком состоянии находится соединение с базой данных. Соединения с базой данных с отслеживанием состояния не могут быть легко поддержаны, поскольку они могут выйти из строя в любой момент (приложение должно помнить, в каком состоянии оно находилось. в середине и повторить). Их можно просто повторно подключить и повторно выполнить (атомарную) команду без (в большинстве случаев) нарушения состояния.
Большинство людей не понимает, что у писателей всегда есть эксклюзивная блокировка, вне зависимости от того, являются ли они частью явной транзакции или нет.