На форуме "ERP и учетные системы" мимоходом возник диспут о достоинствах и недостатках версионников и блокировочников начиная вот с этого места.
цитата Пример : В базе данных в разных таблицах находятся значения A и B, которые исходя из их согласованности никогда не должны быть равны (что проверяется триггером). В исходном состоянии A=1; B=2.
На версионнике одновременно запускаются две транзакции. Одна пытается присвоить A:=5, другая пытается присвоить B:=5. В каждой из этих транзакций считываются значения A и B ДО их запуска. Срабатывает триггер в транзакции №1 и проверяет (А=5) != (B=2) - значит изменение A разрешено. Срабатывает триггер в транзакции №2 и проверяет (A=1) != (B=5) - значит изменение B тоже разрешено. Обе транзакции сохраняют новые значения A и B и закомичивают свои транзакции, новые версии A=5 и B=5 сохраняются в базе данных, нарушив согласованность данных. Такая ситуация не может произойти на блокировочнике.
Тема весьма неоднозначная. По моему убеждению "чистых" версионников сейчас практически не существует (не уверен, поскольку не со всеми СУБД знаком достаточно близко). В той или иной степени любай СУБД является гибридом версионника и блокировочника. На тех СУБД, которые принято считать версионниками, указанная в примере проблема разрешается с помощью блокировок , выполняемых принудительно или "на автомате". Или с помощью микрооткатов, выполняемых при обнаружении факта модификации ранее считанных данных и повторного выполнения транзакции (это может отрицательно сказаться на быстродействии, поскольку происходит лишняя загрузка сервера напрасно выполняемыми операциями). Многие "версионники" (точнее, полагаемые таковыми) могут попадать в дедлок, который возможен только по причине блокировок. То есть, "версионники" сближаются с "блокировочниками". "Блокировочники" в свою очередь делают шаги навстречу версионникам. В частности, в MS SQL Server 2005 реализована возможность выполнения транзакций аналогично версионнику. То есть, грани постепенно стираются. Это, собственно, моя точка зрения.

Опоненты считают (если я их правильно понял), что любой "версионник" в любом случае лучше блокировочника, и описанную мною в примере проблему может обойти методами именно "версионника", не превращаясь при этом в "немножко блокировочник". Прошу высказать свои мнения по этому вопросу.

cav_incУровни изоляции транзакций. В блокировочниках для отката транзакций приходится вести журнал транзакций (MS SQL). В версиониках "чистых" данная ситуация разруливатся на уровне изоляции транзакций.Уровни изоляции транзакций бывают разные. И для того, чтобы реализовать все возможные варианты уровней изоляции, приходится предпринимать в "блокировочниках некоторые гибридные решения. Кроме самих уровней изоляции, которые всего лишь декларируют наборы гарантий той или иной совокупности, в этих гарантиях ничего не сказано о механизмах разрешения возникающих конфликтов одновременного доступа к данным. Каждая СУБД решает такие конфликты немного по-своему. Блокировочники решают конфликты доступа ожиданием освобождения ресурса. Некоторые "версионники" (так называемые), решают эти конфликты точно так же - ожиданием (то есть блокировкой). Так что уровни изоляции уровнями изоляции, а конфликты одновременного доступа к данными - от них никуда не деться.

cav_incВне зависимости от того какя транзакция завершилась первой, вторая будет откаченаЭто в какой СУБД так произойдет? И можно поподробнее, каким образом произойдет откат. То есть, в транзакции стоит "commit", а выполняется "rollback", причем молча (клиент думает, что транзакция закоммичена, а на самом деле все не так)? Если не молча, то какого рода ошибка при этом возникает и можно ли ее каким-то образом обработать? Если можно, то что указывается в конце обработки ошибки - что-то вроде "commit commit" либо "rollback commit"? Если обработка ошибки невозможна, то это решение очень похоже на работу блокировочника с автоматическим "разруливанием" дедлока.

iscrafmGarya, для темы лучше конечно пример подобрать покорректней, а не с deadlock-ом.Нет, как раз именно этот пример и интересен! :) Кроме того, возникнет дедлок или не возникнет, на блокировочнике это зависит от установленного уровня изоляции транзакций. При разрешенном "грязном чтении" дедлока не будет. Что забавно, как раз "грязное чтение" разрешает выполняться транзакцияфм одновременно на блокировочнике и при этом обнаружить нарушение логической целостности. То есть, самостоятельно выдать команду "rollback" как минимум на одной из транзакций.

Dimitry SibiryakovИ тему лучше переместить в проектирование базА при чем тут "проектирование"? Речь идет именно о "сравнении СУБД", разве не так?

Dimitry SibiryakovТам ее затопчут с диким гиканьем поскольку ограничения на триггерах ненадежны по определению, а "В базе данных в разных таблицах находятся значения A и B, которые исходя из их согласованности никогда не должны быть равны" попахивает нарушением НФ.Разумеется, пример сильно упрощенный. Разумеется, в большинстве СУБД можно применить либо DRI, либо check conctraint, на работу которых уровни изоляции транзакций никаким образом не влияют - они выполнятся в любом случае, сгенерив ошибку либо до начала транзакции, либо при попытке ее закоммитить. Но большинство из присутствующих знают ограничения применимости DRI и check conctraint для многих СУБД, и смогут придумать аналогичный, но более сложный пример, требующий промежуточных вычислений и соблюдения более сложных условий, которые проверить можно будет только либо в триггере, либо в ХП. Дабы не отвлекать свои извилины на те многочисленные нюансы, которые не имеют непосредственного отношения к рассматриваемому вопросу, я привел максимально упрощенный пример, для которого, разумеется, есть альтернативные решения в большинстве СУБД. Но я предлагаю исходить из того, что их нет. Мы рассматриваем работу именно транзакций в рамках логики, которую прописываем руками в триггере, либо в ХП. Требование A!=B, разумеется, надуманное, и вполне может не соответствовать всяким там НФ, но в жизни могут быть ситуации со схожими условиями. Пример приводить не стану, а то некоторые заточенные на решение задач, а не на анализ причин их возникновения, начнут рассматривать варианты решения задачи уже в новом примере реорганизацией структуры данных, даже в сторону денормализации... :)

ЛППоставь блокировочнику уровень изоляции Read Committed - и будет тот самый описанный эффект, который якобы "не может произойти на блокировочнике".Будет дедлок. Если есть механизмы автоматического выявления дедлоков, то одна из транзакций будет "насильно откачена" с возвратом клиенту сообщения об ошибке. Или Вы считаете иначе?

ЛППоставь версионнику уровень изоляции Repeatable Read или выше - будет все нормально, в смысле одна из транзакций отлуп получит на коммите (в гипотетическом "чистом" версионникеА что сделает "чистый версионник" на коммите, если он не выставляет блокировок чтения? Каким образом он определит, что транзакцию необходимо откатить?

softwarer GaryaНа форуме "ERP и учетные системы" мимоходом возник диспут о достоинствах и недостатках версионников и блокировочников
Хм. Когда я только появился на форуме, именно в "Сравнении СУБД" была тема страниц на двадцать, и там обсудили все мыслимые вопросы. Сказать имхо больше просто нечего.Я нашел обсуждение только различий в производительности. Меня же интересуют механизмы их работы. "Чистых" версионников, не использующих блокировки, мне неизвестно.

Мимопроходящий"А настоящему Гаре всегда есть что сказать!
Если, конечно, он настоящий Гаря!..""А настоящему Мимопроходящему всегда есть что сказать!
Если, конечно, он настоящий Мимопроходящий!.." :)

ЛПИ чем, собственно, какой-то непонятно откуда взявшийся unique constraint лучше/хуже чем, скажем, обычный констрейнт типа FieldA <> FieldBЭто Check conctraint. Поскольку FieldA и FieldB расположены в РАЗНЫХ таблицах, то не во всех СУБД его можно так просто реализовать. В MS SQL Server 2000, например, придется задействовать UDF, которая выполняется в транзакции и которая может работать по-разному в зависимости от установленного уровня изоляции транзакций. То есть, выйти на "затранзакционный" уровень, не зависящий от уровней изоляции, не удастся.

ЛПДа откуда же ему взяться - на уровне RC?
Первый прочитал - все ок, блокировок еще никаких нет.
Второй прочител - все ок, блокировок еще никаких нет.
Первый проапдейтил первую запись - первая запись заблокирована.
Второй проапдейтил вторую запись - вторая запись заблокирована.
Первый коммит.
Второй коммит.
Где дедлок, я вас спрашиваю? :)Пожалуй, Вы правы. Дедлок может и не возникнуть. И на уровне изоляции RC нарушение логической целостности возможно также на блокировочнике.

ЛПВидать чего-нибудь сравнит, да и поймет чего-нить ненароком :)
Благо сравнивать ему есть чего, версии остались и "изначальная", и "текущая".Сейчас много чего скажу...
Нормальный "псевдоверсионник" должен сравнивать не всё подряд, а флаги (признаки) изменения некоторых данных. Просто это гораздо менее затратно, нежели перелопачивать и сравнивать кучу версий (особенно, если этих версий не 2-3, а 20-30). А выставление подобных флагов - это и есть механизм установки блокировок.
Теперь рассмотрим "специфический случай" обработки транзакции блокировочником. Допустим, в начале транзакции мы создаем временные таблицы и переписываем в них все данные, которые нам потребуются в процессе выполнения транзакции. Измененные и новые значения мы также записываем во временные таблицы. Перед завершением транзакции переписываем результат в рабочие таблицы. Чем в корне такая работа отличается от работы "версионника"? Тем, что часть этой работы "версионник" выполняет сам, без дополнительных усилий со стороны разработчика. Но при этом операции чтения для снятия копий читаемых данных, а также операции записи остаются в рамках транзакции и подчиняются установленным уровням изоляции. Версионник, насколько я понимю, точно так же выставляет признаки блокировки и точно так же их проверяет как блокировочник - при попытке записи версии. Для разработчика же эта процедура КАЖЕТСЯ находящейся за пределами транзакции. Тем не менее, именно при выполнении этой процедуры может возникнуть три десятка разнообразных ошибок из-за конфликтов доступа к данным, обработать по-человечески которые, как правило, уже невозможно. Можно только ознакомиться с фактом возникновения ошибки и откатиться.
Теперь еще пара слов о быстродействии. Снятие копии с данных для формирование версии и сохранение данных версии (итого, две операции копирования) - это неизбежные потери на копирование информации. В некоторых случаях в таком копировании просто нет необходимости (например, при обращении к таблице, в которую информация никогда не пишется, а только читается). Версионник же "молча" производит такое копирование в любом случае (или не в любом? может быть, есть более "интеллектуальные" версионники?).
Вот чего я не понимаю, так это "грязное чтение" на версионниках. Оно там вообще не возможно? А ведь в некоторых (согласен, весьма редких) случаях оно может оказаться полезным. Например, в случае с данным примером оно может позволить выявить редактирование данных другой транзакцией и осмысленно обработать эту ситуацию.