Здравствуйте, Merle, Вы писали:

R>>Брр... Многое зависит от параметров транзакции. В любм случае при фиксации Т2 на клиентскую часть, породившую Т1 пойдет сообщение о deadlock, что решит клиент — его дело.
M>А дедлок-то тут причем? Тем дальше в лес, тем толще партизаны.

Угу из http://www.ibase.ru/devinfo/ibtrans.htm :
Термином deadlock в IB одновременно обозначают два понятия — взаимоблокировку транзакций и конфликт обновления данных.
Как говориться — понимай, что случилось, из контекста

M>Насколько я понимаю, возможно наличие только одной незафиксированной версии данных. Из твоих слов можно заключить, что даже если T1 ждет на блокировке, и таки дожидается, когда T2 зафиксируется, то T1 все равно откатят?
M>Тоесть дожидаться имеет смысл только в надежде на то, что T2 обломается по своим причинам?

Да, именно так.

R>>Может-может
M>Не, клиент тут ничего не может, а вот TM определяет, что транзакции конфликтны и поступает в соответствии с рекомендациями клиента.

Это как посмотреть. Сервер не позволяет провести действие, вызвавшее конфликт обновления, а не транзакцию. Клиент может сделать commit. Правда, я не представляю, для чего это может быть нужно, утвердить только часть измененийв транзакции.

M>А что есть здесь клиентская чать?

Клиент.

КДВ>>Собственно, в IB конфликтуют только транзакции, которые пытаются обновить одну и ту же запись одновременно.
M>Ну, логично.

КДВ>>И даже это не является причиной для того чтобы сервер пугался и кого-то там откатывал.
M>О кей, давайте разберемся с самого начала.
M>Допустим последовательная история транзакций приводит к конфликту. T1 пытается обновить запись, которую уже обновила T2, но при этом T2 еще не успела зафиксироваться.
M>Далее возможное поведение T1:
M>1. Ожидание на блокировке.
M>2. Откат T1 и новый старт.
M>3. Порождение новой версии данных с которой и работает T1, все разборки произойдут при commit'е (first wins, по классике, кто первый встал, того и тапки, кто не успел, того откатывают)

Ты упустил 4 случай, который собственно и происходит — возникает ошибка (без отката транзакции!) при попытке создать вторую неподтвержденную версию записи.

R>Да, забыл, есть одна проблема — отсутствие места на носителе. Вот это тяжко. У младших версий IB также была возможность порчи БД при выходе за пределы максимального размера файла (2 или 4 Гб)

Ну на самом деле подобных проблем — море, как и в любом другом сервере БД. Главное, что если есть админ и если он следит за СУБД — то это все перестает быть проблемой — он своевременно создаст еще файлы...

Здравствуйте, Igor Trofimov, Вы писали:

iT>Ты упустил 4 случай, который собственно и происходит — возникает ошибка (без отката транзакции!) при попытке создать вторую неподтвержденную версию записи.
И что делает ошибшеяся транзакция, повисает в воздухе до решения клиента?
Что-то здесь какой-то архитектурный подвох мне видится.

Здравствуйте, Merle, Вы писали:

iT>>Ты упустил 4 случай, который собственно и происходит — возникает ошибка (без отката транзакции!) при попытке создать вторую неподтвержденную версию записи.
M>И что делает ошибшеяся транзакция, повисает в воздухе до решения клиента?
M>Что-то здесь какой-то архитектурный подвох мне видится.

Что значит "повисает"? Транзакция остается транзакцией — клиент ее открыл, вкатывает данные, в конце либо commit либо rollback. Если считать, что транзакция от старта до окончания повисает, тогда да, висит

Здравствуйте, Romkin, Вы писали:
R>Что значит "повисает"? Транзакция остается транзакцией — клиент ее открыл, вкатывает данные, в конце либо commit либо rollback. Если считать, что транзакция от старта до окончания повисает, тогда да, висит
Как-то странно это. Ну вот открыл я транзакцию. Работаю-работаю. С клиента. Возникает у меня этот дедлок. И что, я после этого могу продолжать работу? Или сделать commit? Или просто сидеть в бесконечном цикле, а сервер будет удерживать транзакцию в неопределенном состоянии?
Просто в рамках MS SQL к моменту deadlock кто-то просто должен сделать rollback. Этого каравая выбирает сервер (чтобы не было бессмысленных препирательств типа "а почему я?"). Ждать, пока клиент скажет "Да, rollback" смысла нет, т.к. ничего другого он сделать не может.

Здравствуйте, Romkin, Вы писали:

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

Интересно, а зачем тогда в IB присутствует версионность метаданных? Любое изменение схемы в любой момент времени _не должно_ влиять на надежность работы с БД. Это заложено архитектурно. Все прочее есть гнусные баги

Здравствуйте, Merle, Вы писали:

M> Допустим последовательная история транзакций приводит к конфликту.
M> T1 пытается обновить запись, которую уже обновила T2, но при этом
M> T2 еще не успела зафиксироваться.
M> Далее возможное поведение T1:
M> 1. Ожидание на блокировке.
M> 2. Откат T1 и новый старт.

Не угадал. Инициация исключения и доставка оного на клиентскую сторону. И все. После чего транзакция может быть подтверждена частично или произведен откат.

Или ты предлагаешь при конфликте делать рестарт транзакции и накат всех изменений, предшествующих конфликту? Интересно узнать, какая СУБД так поступает...

M> Кто принимает решение о дальнейшем развитии событий? Клиент?
M> Не, не может быть..

Еще как может

Здравствуйте, Merle, Вы писали:

M> В конечном итоге в IB,как я понимаю гарантии восстановления таки нет.
M> Если же подробнее, то некое подобие Undo-журнала встроено непосредственно
M> в Transaction Manager, соответственно при нормальной работе в случае сбоя
M> все в порядке. Но, поскольку при данной реализации физически "журнал"
M> перемешан с живыми данными, то сбой при чистке "журнала", приводит к проблемам.

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

Гарантия целостности обеспечивается механизмом "careful writes", т.е. страница, помечающая данные как закоммиченные (и, следовательно, валидные), всегда будет записана последней. Поэтому все данные, транзакция которых не помечена как подтвержденная, будут восприниматься сервером как to-be-skipped. Именно вследствии этого механизма после любого сбоя (кроме повреждения HDD или использования асинхронного доступа к БД (forced writes = off)) сервер просто рестартует и при доступе к инвалидным данным помечает их для сборки мусора и работает дальше. Т.е. никакого процесса именно _восстановления_ нет в принципе. Что, впрочем, отнюдь не уменьшает отказоустойчивости сервера

Сборщик мусора — несколько более сложный зверек, но тоже был спроектирован с прямым намеком на безопасность. И показатели обратного есть намек на конкретные баги, подлежащие излечению. Т.е. некоторые проблемы здесь действительно имеют место.

Здравствуйте, Sinclair, Вы писали:

S> Просто в рамках MS SQL к моменту deadlock кто-то просто должен
S> сделать rollback. Этого каравая выбирает сервер (чтобы не было
S> бессмысленных препирательств типа "а почему я?"). Ждать, пока
S> клиент скажет "Да, rollback" смысла нет, т.к. ничего другого
S> он сделать не может.

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

Здравствуйте, dimitr, Вы писали:

D>Не угадал. Инициация исключения и доставка оного на клиентскую сторону. И все. После чего транзакция может быть подтверждена частично или произведен откат.
Вот здесь вот явная зависимость от клиента... А если в момент доставки эксепшена клиент отвалился, то по такой схеме все становится очень грустно. Транзакция повисает, в нее упираютя другие транзакции, которым нужны данные уже захваченные ей, и так далее..

D>Или ты предлагаешь при конфликте делать рестарт транзакции и накат всех изменений, предшествующих конфликту? Интересно узнать, какая СУБД так поступает...
Oracle Со многими оговорками и нюансами, понятное дело, но да, примерно так. Да и вообще, классический версионник, по теории, примерно так и должен поступать. И это достаточно логично и оправдано.

M>> Кто принимает решение о дальнейшем развитии событий? Клиент? Не, не может быть..
D>Еще как может
Ну вот не верится мне, что это удачная идея....

Здравствуйте, dimitr, Вы писали:

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

D> Или еще один вариант — я проводил всего один документ и нарвался на эту ошибку. Зачем мне откатывать транзакцию и плодить новые, если я могу сделать несколько повторных итераций "перечитывание — запись" в своей единственной — и рано или поздно добиться успеха или вернуть ошибку?
Повторные итерации по тому же состоянию базы приведут точно к таким же последствиям, а если состояние взято на другой момент, то это уже другая транзакция, если я правильно понял...

M>И что делает ошибшеяся транзакция, повисает в воздухе до решения клиента?

Что значит "что делает"? Транзакция ничего не делает. Делает только клиент. Вот он делает, делает, хоба — ошибка.. Ну и сам решает, чего дальше — откатить или что-то другое делать...

S>Как-то странно это. Ну вот открыл я транзакцию. Работаю-работаю. С клиента. Возникает у меня этот дедлок.

ЭТО НЕ ДЕДЛОК!!! Никто никого не блокирует. Просто возникает ошибочка, о которой клиент тотчас узнает.


S> И что, я после этого могу продолжать работу?

Да

S>Или сделать commit?

Да. Или rollback.

S>Или просто сидеть в бесконечном цикле, а сервер будет удерживать транзакцию в неопределенном состоянии?

Ну, если хочешь — сиди Клиент этим заведует, КЛИЕНТ. Что значит "в неопределенном состоянии"? В состоянии активной транзакции.


S>Просто в рамках MS SQL к моменту deadlock кто-то просто должен сделать rollback. Этого каравая выбирает сервер

НЕ БЫЛО DEADLOCK в описываемой тобою ситуации.

M>Вот здесь вот явная зависимость от клиента... А если в момент доставки эксепшена клиент отвалился, то по такой схеме все становится очень грустно. Транзакция повисает, в нее упираютя другие транзакции, которым нужны данные уже захваченные ей, и так далее..

Во-первых, заметим, что "нужны данные, захваченные ей" — это прерогатива блокировочников.
В IB обычно трензакции не блокируют чтений. Единственный случай "захваченных данных" — это уже упоминавшееся обновление записи, которую уже обновили и неподтвердили.

Во-вторых, через пару минут транзакция отвалится сама. И потом — чем это отличается от блокировочника? Вот он начал транзакцию, чего-то поменял, при этом пошла блокировка НА ЧТЕНИЕ!!! И вот бац — сеть просто вдруг пропала. Он тоже не сразу это обнаружит, зато данные будут заблокированы и на чтение ТОЖЕ! Что хуже?

Здравствуйте, Igor Trofimov, Вы писали:

iT>Во-первых, заметим, что "нужны данные, захваченные ей" — это прерогатива блокировочников.
iT>В IB обычно трензакции не блокируют чтений. Единственный случай "захваченных данных" — это уже упоминавшееся обновление записи, которую уже обновили и неподтвердили.
Имеются ввиду пишущие транзакции конечно же...

iT>Во-вторых, через пару минут транзакция отвалится сама.
Пара минут — это на самом деле чертова туча времени...

iT>И потом — чем это отличается от блокировочника? Вот он начал транзакцию, чего-то поменял, при этом пошла блокировка НА ЧТЕНИЕ!!! И вот бац — сеть просто вдруг пропала.
От сети это никак не зависит. Транзакция пришла целиком на сервер и начала исполняться, в этот момент клиент уже никого не интересует, транзакция известна от начала до конца и ясно как с ней поступать в любом случае.
Информация о ходе транзакции конечно может отправяться на клиента, но работа сервера от гарантии доставки этой ниформации никак не зависит.

iT> Он тоже не сразу это обнаружит, зато данные будут заблокированы и на чтение ТОЖЕ! Что хуже?
Как ни странно, но основные потери в блокировочнике идут не непосредственно от самих блокировок, уж больно хорошо вылизан этот механизм, а от побочных эффектов типа дедлоков, да и просто от неаккуратного программирования.

Здравствуйте, Merle, Вы писали:

M>От сети это никак не зависит. Транзакция пришла целиком на сервер и начала исполняться, в этот момент клиент уже никого не интересует, транзакция известна от начала до конца и ясно как с ней поступать в любом случае.

Ну если так, то да... согласен. В случае пакета команд, оформлденного в транзакцию — конечно надежнее получается управление транзакцией с сервера.

M>Как ни странно, но основные потери в блокировочнике идут не непосредственно от самих блокировок, уж больно хорошо вылизан этот механизм, а от побочных эффектов типа дедлоков, да и просто от неаккуратного программирования.

Ну, так я и не говорю, что там плохо что-то.. Везде свои плюсы и минусы.

Здравствуйте, Merle, Вы писали:

M> При таком сценарии нет смысла пускать все одной транзакцией.
M> Это вполне потянет на 200 отдельных транзакций, документы-то
M> независимы...

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

M> Пускать пакет операторов в одной транзакции имеет смысл только
M> тогда, когда ошибка в любом из них, приводит базу в несогласованное
M> состояние, а значит необходимо откатить все изменения в случае сбоя.

Только теоретически. Одна транзакция для батча может, например, использоваться для уменьшения нагрузки на сервер. И между прочем, SQL-стандарт (и ведущие производители СУБД) поддерживают т.н. точки сохранения (savepoints), которые предназначены для частичного отката изменений в случае локальной ошибки и последующего продолжения транзакции. Это все же не от дурной башки придумали, наверное?

M> Повторные итерации по тому же состоянию базы приведут точно к таким
M> же последствиям, а если состояние взято на другой момент, то это уже
M> другая транзакция, если я правильно понял...

Не обязательно. Моя транзакция может работать в режиме изоляции "read-committed" и, получив отлуп и перечитав изменения, уже _закоммиченные_ моим конкурентом, принять решение о повторной записи.

Здравствуйте, Merle, Вы писали:

M> Вот здесь вот явная зависимость от клиента...

И что тут плохого? Это просто альтернативная реализация, которая имеет свои достоинства и недостатки.

M> А если в момент доставки эксепшена клиент отвалился, то по
M> такой схеме все становится очень грустно. Транзакция повисает,
M> в нее упираютя другие транзакции, которым нужны данные уже
M> захваченные ей, и так далее..

Сервер обнаруживает обрыв соединения и откатывает все транзакции скоропостижно скончавшегося клиента.

M> Oracle Со многими оговорками и нюансами, понятное дело, но да,

Не поделишься линком на эту тему? Если честно, я плохо представляю, как Оракл это может сделать.

M> примерно так. Да и вообще, классический версионник, по теории,
M> примерно так и должен поступать. И это достаточно логично и оправдано.

Теория — это нечно слишком абстрактное в нашем отнюдь не идеальном мире

Здравствуйте, dimitr, Вы писали:

D>Да, ты абсолютно прав в том, в IB данные и лог отмены лежат вместе в БД. По крайней мере, это так выглядит внешне, хотя с точки зрения сервера никакой разницы между ними нет. В этом и есть смысл версионности.

Стоп — давайте отделим мух от котлет: версионность — это все-таки методика concurrency control, а журналирование — механизм обеспечения crash recovery.

D>Гарантия целостности обеспечивается механизмом "careful writes", т.е. страница, помечающая данные как закоммиченные (и, следовательно, валидные), всегда будет записана последней. Поэтому все данные, транзакция которых не помечена как подтвержденная, будут восприниматься сервером как to-be-skipped. Именно вследствии этого механизма после любого сбоя (кроме повреждения HDD или использования асинхронного доступа к БД (forced writes = off)) сервер просто рестартует и при доступе к инвалидным данным помечает их для сборки мусора и работает дальше. Т.е. никакого процесса именно _восстановления_ нет в принципе. Что, впрочем, отнюдь не уменьшает отказоустойчивости сервера

Вы рассматриваете частный случай, когда изменение затрагивает только запись в таблице, когда объект записи = single B-Tree leaf page. Как насчет обеспечения recovery после сбоя, когда сервер фиксировал на диск изменения в "потрохах" B-Tree, т.е. после page split / page merge, если одна страница записалась на диск, а другая — нет?

Вообще, насколько я понимаю (я не профессионал в database internals, так что да поправят меня знающие люди), любая операция, которая переводит образ базы на диске из одного (согласованного) состояния в другое и при этом не атомарна с точки зрения disk I/O (пишет более одного disk I/O unit) — должна быть сначала продублирована где-нибудь в другом месте (в журнале), иначе восстановление после сбоя в общем случае невозможно.

D>Сборщик мусора — несколько более сложный зверек, но тоже был спроектирован с прямым намеком на безопасность. И показатели обратного есть намек на конкретные баги, подлежащие излечению. Т.е. некоторые проблемы здесь действительно имеют место.

Ниччего не понимаю (с). Не поясните более подробнее, что Вы имели в виду?