Системные транзакции и бизнес-транзакции
В продолжение первого вопроса второй вопрос. Почему не ассоциировать один к одному бизне и системные транзакции? Чем плохи длинные системные транзакции? Единственный аргумент, который я слышал это снижение масштабируемости. Но в чем принципиальная сложность поддержки большого числа открытых транзакций со стороны СУБД?
1. Если наши бизнес-правила таковы, что можно применять оптимистическую блокировку, то сейчас в SQL Server 2005 есть новый уровень изоляции Snapshot.
2. Если нужна пессимистическая блокировка, то это обычный serialsable уровень изоляции. Единственная проблема в то, что СУБД будет ждать блокировку, а нам требуется сказать, что данные заняты другим пользователем. Почему это не вынести в настройки СУБД?
Просто какая-то странная ситуация проблемы параллелизма решаются СУБД, а предлагается их решать на уровне приложения, причем в точности теме же самыми методами.
Может эта проблема уже устарела, она относится к предыдущим версиям SQL Server-а или к другим СУБД?
1. Если наши бизнес-правила таковы, что можно применять оптимистическую блокировку, то сейчас в SQL Server 2005 есть новый уровень изоляции Snapshot.
2. Если нужна пессимистическая блокировка, то это обычный serialsable уровень изоляции. Единственная проблема в то, что СУБД будет ждать блокировку, а нам требуется сказать, что данные заняты другим пользователем. Почему это не вынести в настройки СУБД?
Просто какая-то странная ситуация проблемы параллелизма решаются СУБД, а предлагается их решать на уровне приложения, причем в точности теме же самыми методами.
Может эта проблема уже устарела, она относится к предыдущим версиям SQL Server-а или к другим СУБД?
Единственный аргумент, который я слышал это снижение масштабируемости.И этого достаточно, чтобы их не использовать.
Но в чем принципиальная сложность поддержки большого числа открытых транзакций со стороны СУБД?Да ни в чем, подохнет сервер и все. Какой, ты думаешь, предел числа коннектов у мощных СУБД типа Oracle или DB2?
А бизнес-транзакции не должны уметь переживать плановую перезагрузку или апгрейд серверов? Нефатальные сбои?
Они не могут длиться днями и более, например, если регламент предусматривает участие человека?
Книжку не читал.
Они не могут длиться днями и более, например, если регламент предусматривает участие человека?
Книжку не читал.
еще один минус длинных транзакций - рост размера базы, накопление "мусора".
откуда мусор? я так полагал, что длинные транзакции требуют разве что большего размера undo tablespace... (в оракле)
Глючит его, и пессимистическую, и оптимистическую блокировку там реализовать можно.
По теме, в Оракле проблем с длинными транзакциями нет.
Главное предусмотреть достаточные сегменты отката.
И рекомендуют коммитить транзакцию, только когда это необходимо.
Обратное черевато дополнительным расходом ресурсов.
По теме, в Оракле проблем с длинными транзакциями нет.
Главное предусмотреть достаточные сегменты отката.
И рекомендуют коммитить транзакцию, только когда это необходимо.
Обратное черевато дополнительным расходом ресурсов.
Оставить комментарий
6yrop
Читаю сейчас книжку Фаулера "Архитектура корпоративных программных приложений" и что-то не догоняю. Рассмотрим простую и наиболее часто встречающуюся ситуацию. Есть СУБД, (пусть даже конкретная SQL Server 2005) и есть многопользовательская система, которая работает с одной базой данных. Тогда системная транзакция это транзакция SQL Servr-а. В книге говориться, что бизнес-транзакция может охватывать несколько системных транзакций. Как при этом осуществляется Атомарность бизнес-транзакции? т.е. если бизнес транзакция состоит из двух системных транзакций A и B, то, как будет осуществляться откат (rollback если транзакция A завершилась успешно и закомитилась, а транзакция B завершилась неуспешно?