Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 .. 14   вперед  Ctrl
 Версионники и блокировочники  [new]
Garya
Member

Откуда: Москва
Сообщений: 33210
Блог
На форуме "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 реализована возможность выполнения транзакций аналогично версионнику. То есть, грани постепенно стираются. Это, собственно, моя точка зрения.

Опоненты считают (если я их правильно понял), что любой "версионник" в любом случае лучше блокировочника, и описанную мною в примере проблему может обойти методами именно "версионника", не превращаясь при этом в "немножко блокировочник". Прошу высказать свои мнения по этому вопросу.
26 сен 06, 09:52    [3183073]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
cav_inc
Member

Откуда: г. Кемерово
Сообщений: 123
Уровни изоляции транзакций. В блокировочниках для отката транзакций приходится вести журнал транзакций (MS SQL). В версиониках "чистых" данная ситуация разруливатся на уровне изоляции транзакций. Вне зависимости от того какя транзакция завершилась первой, вторая будет откачена
26 сен 06, 10:14    [3183189]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Garya

Garya, для темы лучше конечно пример подобрать покорректней, а не с deadlock-ом.
26 сен 06, 10:17    [3183207]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54812

И тему лучше переместить в проектирование баз. Там ее затопчут с диким
гиканьем поскольку ограничения на триггерах ненадежны по определению, а
"В базе данных в разных таблицах находятся значения A и B, которые
исходя из их согласованности никогда не должны быть равны" попахивает
нарушением НФ.

Posted via ActualForum NNTP Server 1.3

26 сен 06, 10:34    [3183337]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
AI
Member

Откуда: Москва
Сообщений: 2817
Чистые "версионники" есть только в воспаленных мозгах теоретиков из-за чрезмерно большого количества накладных расходов. Поэтому в любой СУБД будут блокировки как простой и легкий способ обеспечения изолированности и согласованности транзакций. Триггеры тут абсолютно не при чем.

В общем, надо смотреть не на "версионник" или "блокировочник", а на правила работы читателя-писателя. Это определяет подход к разработке приложений под конкретную СУБД.

Для оракла (любой версии), например, правила доступа к одним и тем же данным таковы: "читатель не блокирует читателя", "читатель не блокирует писателя", "писатель не блокирует читателя", "писатель блокирует писателя". Неблокируемость читателя обеспечивается созданием нужной для него версии данных, писатели же работают с последней версией данных.
26 сен 06, 10:44    [3183421]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ЛП
Guest
2 Garya
Пример какой-то невнятный. Я бы даже сказал - неправильный пример.
Поставь блокировочнику уровень изоляции Read Committed - и будет тот самый описанный эффект, который якобы "не может произойти на блокировочнике".
Поставь версионнику уровень изоляции Repeatable Read или выше - будет все нормально, в смысле одна из транзакций отлуп получит на коммите (в гипотетическом "чистом" версионнике, в гибридном может и раньше отвалиться).

---------------------

2 Dimitry Sibiryakov
"В базе данных в разных таблицах находятся значения A и B, которые
исходя из их согласованности никогда не должны быть равны" попахивает
нарушением НФ.

Ну нарушение НФ, ну и что? Не все же в 5-ой НФ базы делают :)
К рассмотрению различий версионников и блокировочников - вопросы нарушения нормальных форм если и имеют, то какое-то весьма и весьма далекое отношение.
26 сен 06, 10:52    [3183472]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ЛП
Guest
AI
Для оракла (любой версии), например, правила доступа к одним и тем же данным таковы: "читатель не блокирует читателя", "читатель не блокирует писателя", "писатель не блокирует читателя", "писатель блокирует писателя". Неблокируемость читателя обеспечивается созданием нужной для него версии данных, писатели же работают с последней версией данных.

Скажите, а Select For Update - эт в какой СУБД?
:)
26 сен 06, 10:53    [3183485]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
Garya
На форуме "ERP и учетные системы" мимоходом возник диспут о достоинствах и недостатках версионников и блокировочников

Хм. Когда я только появился на форуме, именно в "Сравнении СУБД" была тема страниц на двадцать, и там обсудили все мыслимые вопросы. Сказать имхо больше просто нечего.
26 сен 06, 11:01    [3183526]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896

Привет, softwarer!
Ты пишешь:

softwarer
s> Хм. Когда я только появился на форуме, именно в "Сравнении СУБД"
s> была тема страниц на двадцать, и там обсудили все мыслимые
s> вопросы. Сказать имхо больше просто нечего.
перефразирую известную советскую фильму:
"А настоящему Гаре всегда есть что сказать!
Если, конечно, он настоящий Гаря!.."

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

26 сен 06, 11:05    [3183550]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54812

ЛП

Ну нарушение НФ, ну и что? Не все же в 5-ой НФ базы делают :)
К рассмотрению различий версионников и блокировочников - вопросы
нарушения нормальных форм если и имеют, то какое-то весьма и весьма
далекое отношение.

Просто ни те ни другие не дадут нарушить unique constraint независимо от
уровня трансизоляции и фазы луны. А описанная проблема именно так и
решается.

Posted via ActualForum NNTP Server 1.3

26 сен 06, 11:06    [3183552]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
ЛП
Скажите, а Select For Update - эт в какой СУБД?

Скажите, а select for update не пишет никуда ни байта данных? :)
26 сен 06, 11:10    [3183579]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Garya
Member

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

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

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

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

Dimitry Sibiryakov
Там ее затопчут с диким гиканьем поскольку ограничения на триггерах ненадежны по определению, а "В базе данных в разных таблицах находятся значения A и B, которые исходя из их согласованности никогда не должны быть равны" попахивает нарушением НФ.
Разумеется, пример сильно упрощенный. Разумеется, в большинстве СУБД можно применить либо DRI, либо check conctraint, на работу которых уровни изоляции транзакций никаким образом не влияют - они выполнятся в любом случае, сгенерив ошибку либо до начала транзакции, либо при попытке ее закоммитить. Но большинство из присутствующих знают ограничения применимости DRI и check conctraint для многих СУБД, и смогут придумать аналогичный, но более сложный пример, требующий промежуточных вычислений и соблюдения более сложных условий, которые проверить можно будет только либо в триггере, либо в ХП. Дабы не отвлекать свои извилины на те многочисленные нюансы, которые не имеют непосредственного отношения к рассматриваемому вопросу, я привел максимально упрощенный пример, для которого, разумеется, есть альтернативные решения в большинстве СУБД. Но я предлагаю исходить из того, что их нет. Мы рассматриваем работу именно транзакций в рамках логики, которую прописываем руками в триггере, либо в ХП. Требование A!=B, разумеется, надуманное, и вполне может не соответствовать всяким там НФ, но в жизни могут быть ситуации со схожими условиями. Пример приводить не стану, а то некоторые заточенные на решение задач, а не на анализ причин их возникновения, начнут рассматривать варианты решения задачи уже в новом примере реорганизацией структуры данных, даже в сторону денормализации... :)
26 сен 06, 11:13    [3183610]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ЛП
Guest
2 Dimitry Sibiryakov
Просто ни те ни другие не дадут нарушить unique constraint независимо от уровня трансизоляции и фазы луны.
А описанная проблема именно так и решается.

А при чем здесь unique constraint?
И чем, собственно, какой-то непонятно откуда взявшийся unique constraint лучше/хуже чем, скажем, обычный констрейнт типа FieldA <> FieldB?

------------------

2 softwarer
Скажите, а select for update не пишет никуда ни байта данных? :)

А моё то какое дело? Знать не знаю, и знать не хочу - куда и чего там пишет селект фор апдейт. Вижу "читателя", который исключительно читает данные, но для изменений записи блокированы.
В MS SQL Server'е селекты тоже много чего куда пишут, однако ж селектами не перестают быть, а их аффтары не перестают быть "читателями" (в традиционной терминологии).
26 сен 06, 11:16    [3183630]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Garya
Member

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

ЛП
Поставь версионнику уровень изоляции Repeatable Read или выше - будет все нормально, в смысле одна из транзакций отлуп получит на коммите (в гипотетическом "чистом" версионнике
А что сделает "чистый версионник" на коммите, если он не выставляет блокировок чтения? Каким образом он определит, что транзакцию необходимо откатить?
26 сен 06, 11:22    [3183667]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
Garya
А что сделает "чистый версионник" на коммите, если он не выставляет блокировок чтения?

Поскольку чистый версионник заведомо не выставляет блокировок чтения, вопрос избыточный.

Garya
Каким образом он определит, что транзакцию необходимо откатить?

Хм. Вот пользуюсь я такой замечательной программой StarTeam. И время от времени, когда я хочу сделать check in или check out, она говорит мне: не буду делать операцию, бикоз файл нидс ту би мержед. Тот же самый случай.
26 сен 06, 11:26    [3183696]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
ЛП
Guest
2 Garya
ЛП
Поставь блокировочнику уровень изоляции Read Committed - и будет тот самый описанный эффект, который якобы "не может произойти на блокировочнике".
Будет дедлок.

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

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

Видать чего-нибудь сравнит, да и поймет чего-нить ненароком :)
Благо сравнивать ему есть чего, версии остались и "изначальная", и "текущая".
26 сен 06, 11:34    [3183741]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Мимопроходящий

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

Судя по всему, не только Гаре :)
26 сен 06, 11:55    [3183875]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Yo.!!
Guest
у блокировочника RC не гарантирует даже то что обновляемая запись не будет прочитана из индекса, так что дедлок это не самый худщий вариант ...
26 сен 06, 11:58    [3183894]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67487
Блог
ЛП
Знать не знаю, и знать не хочу - куда и чего там пишет селект фор апдейт.

Ну вот и не называйте его читателем, раз знать не хотите.

ЛП
Вижу "читателя", который исключительно читает данные,

Где?

ЛП
В MS SQL Server'е селекты тоже много чего куда пишут,

Думаю, правильнее будет сказать "могут писать".

ЛП
однако ж селектами не перестают быть, а их аффтары не перестают быть "читателями" (в традиционной терминологии).

"Слово сказанное есть ложь" - или как там звучала эта фраза? Традиционная терминология плохо отрабатывает этот аспект, что хорошо видно в Вашем примере к Гаре.
26 сен 06, 12:01    [3183908]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
cav_inc
Member

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


Всю жизнь думал что так делает IB/FB. А тригер на таблице или некий глобальный сам по себе живущий тригер ? Если на таблице то при ReadCommited и следующей структуре:
автор
/******************************************************************************/
/*** Generated by IBExpert 2004.03.29 26.09.2006 16:13:35 ***/
/******************************************************************************/

SET SQL DIALECT 3;

SET NAMES WIN1251;

CREATE DATABASE 'C:\Project\BugReport\Dbase\BG.FDB'
USER 'SYSDBA' PASSWORD 'masterkey'
PAGE_SIZE 8192
DEFAULT CHARACTER SET WIN1251;



/******************************************************************************/
/*** Exceptions ***/
/******************************************************************************/

CREATE EXCEPTION EXT 'Áëà-Áëà';



/******************************************************************************/
/*** Tables ***/
/******************************************************************************/

CREATE TABLE T1 (
ID INTEGER
);


CREATE TABLE T2 (
ID INTEGER
);





/******************************************************************************/
/*** Triggers ***/
/******************************************************************************/


SET TERM ^ ;




/* Trigger: T1_BU0 */
CREATE TRIGGER T1_BU0 FOR T1
ACTIVE BEFORE UPDATE POSITION 0
AS
declare variable id integer;
begin
/* Trigger text */
if (exists(select id from t2 where id=new.id)) then
exception ext;

end
^

/* Trigger: T2_BU0 */
CREATE TRIGGER T2_BU0 FOR T2
ACTIVE BEFORE UPDATE POSITION 0
AS
declare variable id integer;
begin
/* Trigger text */
if (exists(select id from t1 where id=new.id)) then
exception ext;

end
^


SET TERM ; ^


Возникает исключение на тригере :)
26 сен 06, 12:15    [3184018]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Garya
Member

Откуда: Москва
Сообщений: 33210
Блог
softwarer
Garya
На форуме "ERP и учетные системы" мимоходом возник диспут о достоинствах и недостатках версионников и блокировочников

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

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

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

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

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

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32896
Привет, Garya!
Ты пишешь:

Garya
G> Версионник, насколько я понимю, точно так же выставляет признаки блокировки
G> и точно так же их проверяет как блокировочник - при попытке записи версии.
G> Для разработчика же эта процедура КАЖЕТСЯ находящейся за пределами транзакции.
G> Тем не менее, именно при выполнении этой процедуры может возникнуть три десятка
G> разнообразных ошибок из-за конфликтов доступа к данным, обработать по-человечески которые,
G> как правило, уже невозможно. Можно только ознакомиться с фактом возникновения ошибки и откатиться.

G> Версионник же "молча" производит такое копирование в любом случае
G> (или не в любом? может быть, есть более "интеллектуальные" версионники?).
монетку бросает.
[удалено модератором]
26 сен 06, 12:40    [3184221]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Yo.!!
Guest
Garya

Теперь рассмотрим "специфический случай" обработки транзакции блокировочником. Допустим, в начале транзакции мы создаем временные таблицы и переписываем в них все данные, которые нам потребуются в процессе выполнения транзакции. Измененные и новые значения мы также записываем во временные таблицы. Перед завершением транзакции переписываем результат в рабочие таблицы. Чем в корне такая работа отличается от работы "версионника"?

тем что "это" работать не будет, помнится Злой тут красиво расписал почему.
26 сен 06, 12:45    [3184252]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30273
автор
"Чистых" версионников, не использующих блокировки, мне неизвестно.

о каких блокировках идет речь? версионнику, чистому или "нечистому", блокировки по чтению не нужны, совсем. Блокировок по записи тоже как таковых нет, то есть "заблокированная" изменением запись обнаруживается только при попытке ее update/delete другой транзакцией.

Разумеется, в версионнике есть блокировки на уровне страниц, но это "не те" блокировки. они нужны только для сериализации изменений в пределах одной страницы, и пользователь их ни в каком виде не наблюдает.
26 сен 06, 13:06    [3184432]     Ответить | Цитировать Сообщить модератору
 Re: Версионники и блокировочники  [new]
Yo.!!
Guest
kdv

Разумеется, в версионнике есть блокировки на уровне страниц, но это "не те" блокировки. они нужны только для сериализации изменений в пределах одной страницы, и пользователь их ни в каком виде не наблюдает.

страницы чего ? а главное зачем страницы ? ну и о котором версионнике речь ?
26 сен 06, 13:09    [3184444]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 .. 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить