Поделитесь пожалуйста толковой ссылкой, на то как устроен механизм восстановления после сбоев в InterBase и его клонах...
И как там вообще дела с журналом транзакций обстоят?
Привет, Merle!
Вы пишешь 11 ноября 2003:
M> Поделитесь пожалуйста толковой ссылкой, на то как устроен механизм восстановления после сбоев в InterBase и его клонах... M> И как там вообще дела с журналом транзакций обстоят?
Нету там журнала (в том смысле как у блокировочников).
Здравствуйте, Alex.Che, Вы писали:
M>> И как там вообще дела с журналом транзакций обстоят? AC>Нету там журнала (в том смысле как у блокировочников).
Журнал транзакций, он как бы не завязан на блокировочников, он, как правило, есть и у версионников и у оптимистических блокировочников и у кого хош. Просто это очень удачный способ обеспечения отказоустойчивости.
Без журнала, в том или ином виде, сложновать сделать полноценный механизм восстановления после сбоев с приемлимой производительностью. Вот и стало интересно как в IB это устроено.
AC>Рекомендую http://ibase.ru/devinfo/inplupd.htm AC>Не помешает также: AC>http://ibase.ru/devinfo/oitoat.htm
Спасибо, обязательно почитаю.
Привет, Merle!
Вы пишешь 11 ноября 2003:
M>>> И как там вообще дела с журналом транзакций обстоят? AC>> Нету там журнала (в том смысле как у блокировочников).
M> Журнал транзакций, он как бы не завязан на блокировочников, он, как правило, есть и у версионников
Например? Oracle не в счёт, т.к. большинством голосов его обозвали [b]гибридом[b]
M> и у оптимистических блокировочников и у кого хош. M> Просто это очень удачный способ обеспечения отказоустойчивости. M> Без журнала, в том или ином виде, сложновать сделать полноценный M> механизм восстановления после сбоев с приемлимой производительностью.
Смотря какие сбои иметь в виду.
Теоретически IB "дуракоустойчив". Теоретически
И в идеале, база должна быть всегда валидной (теоретически).
Практика же несколько иная
Здравствуйте, Alex.Che, Вы писали:
AC>Смотря какие сбои иметь в виду. AC>Теоретически IB "дуракоустойчив". Теоретически AC>И в идеале, база должна быть всегда валидной (теоретически). AC>Практика же несколько иная
Я так понимаю, в первую очередь имелся в виду сценарий восстановления после сбоя экземпляра, т.е. после неожиданного завершения работы сервера. Как себя ведет IB в том случае если при запуске он обнаруживает что в прошлый раз его "выдернули из розетки"?
Привет, alexm1202!
Вы пишешь 11 ноября 2003:
AC>> Смотря какие сбои иметь в виду. AC>> Теоретически IB "дуракоустойчив". Теоретически AC>> И в идеале, база должна быть всегда валидной (теоретически). AC>> Практика же несколько иная
a> Я так понимаю, в первую очередь имелся в виду сценарий восстановления после сбоя экземпляра, т.е. после неожиданного завершения a> работы сервера. Как себя ведет IB в том случае если при запуске он обнаруживает что в прошлый раз его "выдернули из розетки"?
Именно так как я написал.
"Поломки" базы случаются в основном, если в момент "выдёргивания" на сервере существовали
активные потоки, собирающие мусор. В остальных случаях, поломки маловероятны.
Причины возникновения "поломок" баз IB, более-менее систематизированы тут: http://ibase.ru/devinfo/db_repair.htm#corrupt
A>Я так понимаю, в первую очередь имелся в виду сценарий восстановления после сбоя экземпляра, т.е. после неожиданного завершения работы сервера. Как себя ведет IB в том случае если при запуске он обнаруживает что в прошлый раз его "выдернули из розетки"?
Не говоря о багах, включенном кешировании записи (non forced writes) и кривостях некоторых инструментов, теоретически — ничего делать не надо. База в валидном состоянии, хоть ты десять раз вилку выдерни. В этом и плюс. И журнал не нужен.
Здравствуйте, Alex.Che, Вы писали:
M>> Журнал транзакций, он как бы не завязан на блокировочников, он, как правило, есть и у версионников AC>Например?
Чего например?
AC>Oracle не в счёт, т.к. большинством голосов его обозвали гибридом
Зверюги, ну гибрид он. То есть не блокировочник, и журнал у него есть.
И у Postgres'а есть, у кого-то конечно нет, но это совершенно не связанные вещи.
Просто идеологически в любой базе, в том или ином виде есть:
1. Transaction Manager, в задачи которого входит обеспечение параллелизма. И в следствии этого, в нем есть подсистема либо Locking Concurrency, либо Multiversioning Concurrency, либо Timestamp Optimistic Concurrency, либо какой-нибудь другой механизм гарантии Serializability.
2. Database Engine, который занимается непосредственно обработкой запросов.
3. И, наконец, есть подсистема Recovery, которая занимается обеспечением восстановления после сбоя.
И Recovery на Transaction Manager очень мало завязана. обычно.
AC>Смотря какие сбои иметь в виду.
Любые, кроме физического повреждения диска.
AC>Теоретически IB "дуракоустойчив". Теоретически
Он должен быть не дуракоустойчив, а отказоустойчив, это немного разные вещи.
AC>И в идеале, база должна быть всегда валидной (теоретически). AC>Практика же несколько иная
Вот об чем и речь.
В принципе ничего криминального в отсутствии журнала нет. Возможны и системы без журнала. Просто это одно из наиболее удачных решений обеспечивающее отказоустойчивость практически без потерь производительности.
Без оного, как правило, вариантов не много. Либо быстрые обновления, но остутствие автоматического восстановления, либо гарантия восстановления, но медленные обновления (или быстрые обновления но медленная фиксация).
В конечном итоге в IB,как я понимаю гарантии восстановления таки нет.
Если же подробнее, то некое подобие Undo-журнала встроено непосредственно в Transaction Manager, соответственно при нормальной работе в случае сбоя все в порядке. Но, поскольку при данной реализации физически "журнал" перемешан с живыми данными, то сбой при чистке "журнала", приводит к проблемам.
Насколько я понял в Yaffi эти проблемы решены.. Интересно как?
Мы уже победили, просто это еще не так заметно...
Re: IB Recovery
От:
Аноним
Дата:
12.11.03 10:41
Оценка:
Здравствуйте, Merle, Вы писали:
M>Поделитесь пожалуйста толковой ссылкой, на то как устроен механизм восстановления после сбоев в InterBase и его клонах...
Востанавливаемость записей организуеться аналогично журналируемой файловой системой(EXT3 NTFS) В общем каждая запись помечаеться handle транзакции, и при просмотре выбираеться актульная. При выключении питания в журнал транзакций пр и пдключении сервера записываеться что она rollback. весь смысл версионноков что они при модификации записи не блокируют её а пораждают новую запись которая при commite признаеться актуальной.
M>И как там вообще дела с журналом транзакций обстоят?
Отсутсвует, в стандарном понимании есть таблица записей где указанно какие транзакции commit а какие rollback
Здравствуйте, Merle, Вы писали:
M>Просто идеологически в любой базе, в том или ином виде есть: M>1. Transaction Manager, в задачи которого входит обеспечение параллелизма. И в следствии этого, в нем есть подсистема либо Locking Concurrency, либо Multiversioning Concurrency, либо Timestamp Optimistic Concurrency, либо какой-нибудь другой механизм гарантии Serializability. M>2. Database Engine, который занимается непосредственно обработкой запросов. M>3. И, наконец, есть подсистема Recovery, которая занимается обеспечением восстановления после сбоя.
M>И Recovery на Transaction Manager очень мало завязана. обычно.
M>В принципе ничего криминального в отсутствии журнала нет. Возможны и системы без журнала. Просто это одно из наиболее удачных решений обеспечивающее отказоустойчивость практически без потерь производительности. M>Без оного, как правило, вариантов не много. Либо быстрые обновления, но остутствие автоматического восстановления, либо гарантия восстановления, но медленные обновления (или быстрые обновления но медленная фиксация).
M>В конечном итоге в IB,как я понимаю гарантии восстановления таки нет. M>Если же подробнее, то некое подобие Undo-журнала встроено непосредственно в Transaction Manager, соответственно при нормальной работе в случае сбоя все в порядке. Но, поскольку при данной реализации физически "журнал" перемешан с живыми данными, то сбой при чистке "журнала", приводит к проблемам. M>Насколько я понял в Yaffi эти проблемы решены.. Интересно как?
Гарантия восстановления данных в IB есть, и очень быстрая. В случае сбоя сервера при следующем подсоединении к БД он просто проходит и помечает страницы с неподтвержденными транзакциями как пустые, на чем все и заканчивается.
А вот менеджера транзакций в понимании блокировочника там нет, журнала также нет, все гораздо проще — есть страницы, и есть версии записей. На основе версий обеспечивается и параллельность, и восстановление. Дело в том, что в каждой версии записывается номер транзакции (TID), которая создала это изменение. Список текущих транзакций также в БД есть. Следовательно, при подключении остается пройти по этому списку и отменить повисшие транзакции. Синхронизация изменений также происходит на основе версий
Сбой в структуре может произойти в следующих случаях:
1. Смерть сервера по форсмажорным электричествам во время сборки мусора (sweep)
2. Отключение forced writes — сервер не знает, данные в кеше системы или уже на диске
3. Некорректные изменения метаданных — во время работы и тд.
4. ... Ну еще несколько причин, не таких основных.
А так — когда база просто работает, внешнее впечатление, что сервер просто не замечает сбоев.
Здравствуйте, Romkin, Вы писали:
R>Гарантия восстановления данных в IB есть, и очень быстрая.
Ну, согласен, с некоторыми оговорками.
R>В случае сбоя сервера при следующем подсоединении к БД он просто проходит и помечает страницы с неподтвержденными транзакциями как пустые, на чем все и заканчивается.
Гуд, я так и написал, тут все очевидно. Просто и "журнал" и данные физически в одном месте. Я "журнал" намеренно беру в кавычки, так как схема работы очень напоминает Undo-журнал "в классическом понимании"
R>А вот менеджера транзакций в понимании блокировочника там нет,
Там нет не менеджера транзакций, а менеджера блокировок. А менеджер транзакций там в полне себе есть. Возможно он называется по другому, но это тот самый механизм, который определяет, что вот эта вот транзакция нарвалась на вот эту вот и ее надо откатить, по бырому, чтобы не отсвечивала.
Это не обязательно остдельный сервер или отдельная часть ядра — это просто специальное название весьма конкретной функциональности.
R>журнала также нет, все гораздо проще — есть страницы, и есть версии записей.
Да. Нет журнала, как отдельного файла или механизма, но схема работы с данными действительно напоминает undo-журнал.
R>Сбой в структуре может произойти в следующих случаях: R>1. Смерть сервера по форсмажорным электричествам во время сборки мусора (sweep)
Вот здесь вот та самая оговорка про отказоустойчивость. Отказоустойчивость должна обеспечиваться и при работе всех обслуживающие механизмов, а здесь ее нет.
R>2. Отключение forced writes — сервер не знает, данные в кеше системы или уже на диске
Естественно, тут никакой журнал не спасет.
R>3. Некорректные изменения метаданных — во время работы и тд.
Вот это тоже непонятно....
R>4. ... Ну еще несколько причин, не таких основных.
В том-то и дело, что при полноценном Recovery никаких причин не должно быть в принципе.
Единственная допускаемая возможность невосстановимого сбоя — это случай физического повреждения носителя. Если же повреждения не произошло, то база обязана сама себя привести в корректное состояние без посторонней помощи.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Alex.Che, Вы писали:
AC>>Oracle не в счёт, т.к. большинством голосов его обозвали гибридом M>Зверюги, ну гибрид он. То есть не блокировочник, и журнал у него есть. M>И у Postgres'а есть, у кого-то конечно нет, но это совершенно не связанные вещи.
по-моему "журнала" у PGSQL нет (могу ошибаться). У него система версионности похожая на IB.
M>Без оного, как правило, вариантов не много. Либо быстрые обновления, но остутствие автоматического восстановления, либо гарантия восстановления, но медленные обновления (или быстрые обновления но медленная фиксация).
я рекомендую почитать статьи общего плана
Общее описание транзакций и архитектур серверов. Л. Козленко. http://www.osp.ru/os/2002/04/067_print.htm http://www.osp.ru/os/2002/05/058_1_print.htm http://www.osp.ru/os/2002/11/062_print.htm http://www.osp.ru/os/2003/02/059_print.htm
M>В конечном итоге в IB,как я понимаю гарантии восстановления таки нет. M>Если же подробнее, то некое подобие Undo-журнала встроено непосредственно в Transaction Manager, соответственно при нормальной работе в случае сбоя все в порядке. Но, поскольку при данной реализации физически "журнал" перемешан с живыми данными, то сбой при чистке "журнала", приводит к проблемам. M>Насколько я понял в Yaffi эти проблемы решены.. Интересно как?
никаких проблем тут нет, и в YA соответственно отсутствующие проблемы никто не решал.
каждая версия записи маркируется номером транзакции. В БД хранится список стостояния транзакций.
Если транзакция committed — версию читать можно. Не committed — нельзя. Вот и все.
Если был сбой, то в списке состояния транзакций их состояния не изменились. Соответственно их
версии остались non-committed, и игнорируются при чтении (и вычищаются как мусор).
Да, при update каждый раз создается новая версия записи, и это слегка замедляет работу.
но как правило кооперативная сборка мусора работает нормально, и большое кол-во версий
накапливается редко.
В общем, никаких проблем с "восстановлением" после сбоя сервера нет.
Здравствуйте, Merle, Вы писали:
R>>А вот менеджера транзакций в понимании блокировочника там нет, M>Там нет не менеджера транзакций, а менеджера блокировок. А менеджер транзакций там в полне себе есть. Возможно он называется по другому, но это тот самый механизм, который определяет, что вот эта вот транзакция нарвалась на вот эту вот и ее надо откатить, по бырому, чтобы не отсвечивала.
как завершать транзакции, commit или rollback, в IB решает ТОЛЬКО клиентская часть. Сервер никогда не занимается самодеятельностью. Потому что в этом нет никакой необходимости. Собственно, в IB конфликтуют только транзакции, которые пытаются обновить одну и ту же запись одновременно. И даже это не является причиной для того чтобы сервер пугался и кого-то там откатывал.
R>>журнала также нет, все гораздо проще — есть страницы, и есть версии записей. M>Да. Нет журнала, как отдельного файла или механизма, но схема работы с данными действительно напоминает undo-журнал.
напоминает.
R>>1. Смерть сервера по форсмажорным электричествам во время сборки мусора (sweep) M>Вот здесь вот та самая оговорка про отказоустойчивость. Отказоустойчивость должна обеспечиваться и при работе всех обслуживающие механизмов, а здесь ее нет.
это достаточно редкий случай, который сейчас исправлен как баг.
R>>4. ... Ну еще несколько причин, не таких основных. M>В том-то и дело, что при полноценном Recovery никаких причин не должно быть в принципе.
неясно, что ты имеешь в виду под Recovery. Давай еще раз услышим определение, в случае каких сбоев надо этот "механизм" применять.
M>Единственная допускаемая возможность невосстановимого сбоя — это случай физического повреждения носителя. Если же повреждения не произошло, то база обязана сама себя привести в корректное состояние без посторонней помощи.
Она и приводит. Просто Romkin излишне углубился в ситуации, которые никакого отношения к версионности не имеют.
Здравствуйте, Кузьменко Д.В., Вы писали:
M>>Насколько я понял в Yaffi эти проблемы решены.. Интересно как?
КДВ>никаких проблем тут нет, и в YA соответственно отсутствующие проблемы никто не решал.
Нет, имелась ввиду не проблема восстановления после сбоя при нормальной работе, а проблема восстановления в том случае, если сбой произошел во время сборки мусора.
Все, что я успел прочитать по этому поводу, а так же сообщения в форуме, говорят о том, что проблема эта есть...
Здравствуйте, Merle, Вы писали:
КДВ>>никаких проблем тут нет, и в YA соответственно отсутствующие проблемы никто не решал. M>Нет, имелась ввиду не проблема восстановления после сбоя при нормальной работе, а проблема восстановления в том случае, если сбой произошел во время сборки мусора. M>Все, что я успел прочитать по этому поводу, а так же сообщения в форуме, говорят о том, что проблема эта есть...
тут все беды от того, что сборщик мусора в 6.0 сделали как отдельный thread. поэтому действительно, иногда бывают повреждения данных при отключениях сервера при сборке мусора. Но я бы не сказал, что этот случай частый. Возможно, на www.ibase.ru вскоре будет опубликована некая статистика по повреждениям баз. Однако, не зная точно общее кол-во установок IB/FB/YA, ее трудно оценивать объективно как общую надежность сервера
А насчет YA (и FB 1.5) м.б. я подобные исправления пропустил, т.к. такие повреждения БД не были, что называется, "на слуху".
Здравствуйте, Merle, Вы писали:
R>>А вот менеджера транзакций в понимании блокировочника там нет, M>Там нет не менеджера транзакций, а менеджера блокировок. А менеджер транзакций там в полне себе есть. Возможно он называется по другому, но это тот самый механизм, который определяет, что вот эта вот транзакция нарвалась на вот эту вот и ее надо откатить, по бырому, чтобы не отсвечивала. M>Это не обязательно остдельный сервер или отдельная часть ядра — это просто специальное название весьма конкретной функциональности.
R>>журнала также нет, все гораздо проще — есть страницы, и есть версии записей. M>Да. Нет журнала, как отдельного файла или механизма, но схема работы с данными действительно напоминает undo-журнал.
Ну да, хотя скорее это напоминает именно версионность
R>>Сбой в структуре может произойти в следующих случаях: R>>1. Смерть сервера по форсмажорным электричествам во время сборки мусора (sweep) M>Вот здесь вот та самая оговорка про отказоустойчивость. Отказоустойчивость должна обеспечиваться и при работе всех обслуживающие механизмов, а здесь ее нет.
Да, к сожалению. Поэтому автоматическую сборку мусора обычно отключают, она нужна редко, поэтому ее делают сразу после бекапа, или просто восстанавливают из бекапа всю БД. Кстати, в Yaffil именно это и исправлено — sweep не представляет опасности.
R>>2. Отключение forced writes — сервер не знает, данные в кеше системы или уже на диске M>Естественно, тут никакой журнал не спасет.
R>>3. Некорректные изменения метаданных — во время работы и тд. M>Вот это тоже непонятно....
В частности, изменение текста хранимой процедуры во время ее использования может привести к повреждению. Поэтому не рекомендуется изменять структуру БД в то время, когда с ней работают.
R>>4. ... Ну еще несколько причин, не таких основных. M>В том-то и дело, что при полноценном Recovery никаких причин не должно быть в принципе.
Все эти причины вполне преодолимы, нужно просто соблюдать чистоту рук так сказать:
-грамотно писать структуру БД, понимая, что такое версионность и как работают проверки целостности
-не лезть изменять метаданные во время работы
-отключить sweep
-включить forced wirtes
M>Единственная допускаемая возможность невосстановимого сбоя — это случай физического повреждения носителя. Если же повреждения не произошло, то база обязана сама себя привести в корректное состояние без посторонней помощи.
При выполнении вышеуказанных условий повреждение базы может произойти фактически только при сбое оборудования (не только носителя, память, к сожалению тоже может сбоить)
Здравствуйте, Кузьменко Д.В., Вы писали:
КДВ> как завершать транзакции, commit или rollback, в IB решает ТОЛЬКО клиентская часть.
Ой. Вот явно чуствуется многоверсионность, сколько людей, столько и объяснений...
А что есть здесь клиентская чать?
КДВ>Собственно, в IB конфликтуют только транзакции, которые пытаются обновить одну и ту же запись одновременно.
Ну, логично.
КДВ>И даже это не является причиной для того чтобы сервер пугался и кого-то там откатывал.
О кей, давайте разберемся с самого начала.
Допустим последовательная история транзакций приводит к конфликту. T1 пытается обновить запись, которую уже обновила T2, но при этом T2 еще не успела зафиксироваться.
Далее возможное поведение T1:
1. Ожидание на блокировке.
2. Откат T1 и новый старт.
3. Порождение новой версии данных с которой и работает T1, все разборки произойдут при commit'е (first wins, по классике, кто первый встал, того и тапки, кто не успел, того откатывают)
Кто принимает решение о дальнейшем развитии событий? Клиент? Не, не может быть..
Насколько я понимаю по умолчанию IB поступает по сценарию 2 (но если попросить, то может и по 1, но это не принято)
Ранее. я грешным делом, думал, что по сценарию 3, но тут меня настойчиво поправили..
КДВ>это достаточно редкий случай, который сейчас исправлен как баг.
Гуд.
А в чем именно была проблема?
КДВ>неясно, что ты имеешь в виду под Recovery. Давай еще раз услышим определение, в случае каких сбоев надо этот "механизм" применять.
В случае любых сбоев, если конечно эт сбои не привели к физической порче диска.
Тоесть любой сбой, во время любой операции должен быть обратимым и база должна сама прийти в согласованное состояние на момент непосредственно перед сбоем. (требование Durability из ACID так же не должно нарушаться. Что зафиксировано — не вырубишь топором)
КДВ>Просто Romkin излишне углубился в ситуации, которые никакого отношения к версионности не имеют.
Дык!
Я изначально про версионность ни гу-гу. Recovery, по идее, ни как не зависит от можели Concurrency. Это четыре разных человека.
Здравствуйте, Merle, Вы писали:
КДВ>>И даже это не является причиной для того чтобы сервер пугался и кого-то там откатывал. M>О кей, давайте разберемся с самого начала. M>Допустим последовательная история транзакций приводит к конфликту. T1 пытается обновить запись, которую уже обновила T2, но при этом T2 еще не успела зафиксироваться. M>Далее возможное поведение T1: M>1. Ожидание на блокировке. M>2. Откат T1 и новый старт. M>3. Порождение новой версии данных с которой и работает T1, все разборки произойдут при commit'е (first wins, по классике, кто первый встал, того и тапки, кто не успел, того откатывают)
Брр... Многое зависит от параметров транзакции. В любм случае при фиксации Т2 на клиентскую часть, породившую Т1 пойдет сообщение о deadlock, что решит клиент — его дело.
В общем, за этим сюда http://www.ibase.ru/devinfo/ibtrans.htm
M>Кто принимает решение о дальнейшем развитии событий? Клиент? Не, не может быть..
Может-может
M>Насколько я понимаю по умолчанию IB поступает по сценарию 2 (но если попросить, то может и по 1, но это не принято)
Как правило, программируется именно это
КДВ>>неясно, что ты имеешь в виду под Recovery. Давай еще раз услышим определение, в случае каких сбоев надо этот "механизм" применять. M>В случае любых сбоев, если конечно эт сбои не привели к физической порче диска. M>Тоесть любой сбой, во время любой операции должен быть обратимым и база должна сама прийти в согласованное состояние на момент непосредственно перед сбоем. (требование Durability из ACID так же не должно нарушаться. Что зафиксировано — не вырубишь топором)
Вроде есть такое. Я, по крайней мере, не жалуюсь, в практике у меня были потери данных только при крахе диска или по моей глупости, но сейчас уже строго — изменения структуры тщательно проверяются.
Здравствуйте, Merle, Вы писали:
КДВ>>неясно, что ты имеешь в виду под Recovery. Давай еще раз услышим определение, в случае каких сбоев надо этот "механизм" применять. M>В случае любых сбоев, если конечно эт сбои не привели к физической порче диска. M>Тоесть любой сбой, во время любой операции должен быть обратимым и база должна сама прийти в согласованное состояние на момент непосредственно перед сбоем. (требование Durability из ACID так же не должно нарушаться. Что зафиксировано — не вырубишь топором)
Да, забыл, есть одна проблема — отсутствие места на носителе. Вот это тяжко. У младших версий IB также была возможность порчи БД при выходе за пределы максимального размера файла (2 или 4 Гб)
Здравствуйте, Romkin, Вы писали:
R>Брр... Многое зависит от параметров транзакции. В любм случае при фиксации Т2 на клиентскую часть, породившую Т1 пойдет сообщение о deadlock, что решит клиент — его дело.
А дедлок-то тут причем? Тем дальше в лес, тем толще партизаны.
Насколько я понимаю, возможно наличие только одной незафиксированной версии данных. Из твоих слов можно заключить, что даже если T1 ждет на блокировке, и таки дожидается, когда T2 зафиксируется, то T1 все равно откатят?
Тоесть дожидаться имеет смысл только в надежде на то, что T2 обломается по своим причинам?
R>Может-может
Не, клиент тут ничего не может, а вот TM определяет, что транзакции конфликтны и поступает в соответствии с рекомендациями клиента.
Здравствуйте, 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. Правда, я не представляю, для чего это может быть нужно, утвердить только часть измененийв транзакции.
Клиент.
КДВ>>Собственно, в 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" смысла нет, т.к. ничего другого он сделать не может.
... << RSDN@Home 1.1.0 stable >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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>И что делает ошибшеяся транзакция, повисает в воздухе до решения клиента?
Что значит "что делает"? Транзакция ничего не делает. Делает только клиент. Вот он делает, делает, хоба — ошибка.. Ну и сам решает, чего дальше — откатить или что-то другое делать...
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>Сборщик мусора — несколько более сложный зверек, но тоже был спроектирован с прямым намеком на безопасность. И показатели обратного есть намек на конкретные баги, подлежащие излечению. Т.е. некоторые проблемы здесь действительно имеют место.
Ниччего не понимаю (с). Не поясните более подробнее, что Вы имели в виду?
Здравствуйте, cheese, Вы писали:
C>Вы рассматриваете частный случай, когда изменение затрагивает только запись в таблице, когда объект записи = single B-Tree leaf page. Как насчет обеспечения recovery после сбоя, когда сервер фиксировал на диск изменения в "потрохах" B-Tree, т.е. после page split / page merge, если одна страница записалась на диск, а другая — нет?
Здесь работа с индексами ничем не отличается от работы с данными. Измененная версия, до фиксации транзакции ее изменившей, не считается актуальной. Так что тут вроде бы все чисто.
C>Вообще, насколько я понимаю (я не профессионал в database internals, так что да поправят меня знающие люди), любая операция, которая переводит образ базы на диске из одного (согласованного) состояния в другое и при этом не атомарна с точки зрения disk I/O (пишет более одного disk I/O unit) — должна быть сначала продублирована где-нибудь в другом месте (в журнале), иначе восстановление после сбоя в общем случае невозможно.
Ну в общем случае все так. И здесь по большому счету тоже самое. Просто фиксация транзакции, одно атомарное действие, начиная с которого все предыдущие изменения, сделанные этой транзакцией, считаются актуальными...
Здравствуйте, dimitr, Вы писали:
D>Только теоретически.
Не, это как раз суровая практика..
D>Одна транзакция для батча может, например, использоваться для уменьшения нагрузки на сервер. И между прочем, SQL-стандарт (и ведущие производители СУБД) поддерживают т.н. точки сохранения (savepoints), которые предназначены для частичного отката изменений в случае локальной ошибки и последующего продолжения транзакции. Это все же не от дурной башки придумали, наверное?
Ну ладно, даже если опустить целесообразность сэйвпоинтов и запуск одним батчем, все равно завязываться не клиента в процессе выполнения нет никакого смысла.
Ведь в 99.9% случаев уже на этапе подготовки транзакции известно, в каком месте ошибка должна приводить к откату, а в каком нет. И вообще как с этой транзакцией поступать в случае сбоя. Для этого вовсе не надо дергать клиента в момент конфликта, никакой дополнительной информации от сервера он не получит.
D>Не обязательно. Моя транзакция может работать в режиме изоляции "read-committed" и, получив отлуп и перечитав изменения, уже _закоммиченные_ моим конкурентом, принять решение о повторной записи.
Ну правильно. Это и есть откат и новый старт транзакции по новой версии данных.
Здравствуйте, dimitr, Вы писали:
D>И что тут плохого?
Зависимость от клиента...
D>Это просто альтернативная реализация, которая имеет свои достоинства и недостатки.
Вот именно эта реализация, в этом месте как раз имеет явный недостаток.
В 99.9% случаев известно еще на этапе подготовки транзакции, что с ней делать в случае сбоя. И дергать клиента нет никакого смысла.
D>Сервер обнаруживает обрыв соединения и откатывает все транзакции скоропостижно скончавшегося клиента.
Ну обрыв-то обнаруживается не сразу...
D>Не поделишься линком на эту тему? Если честно, я плохо представляю, как Оракл это может сделать.
Ну все есть в доке, на oracle.com. Потом есть двухтомный талмуд Тома Кайта, где все это очень хорошо расписано. И, в конце концов, мекка всех ораклоидов сайт вышеупомянутого Тома: http://asktom.oracle.com
C>Вообще, насколько я понимаю (я не профессионал в database internals, так что да поправят меня знающие люди), любая операция, которая переводит образ базы на диске из одного (согласованного) состояния в другое и при этом не атомарна с точки зрения disk I/O (пишет более одного disk I/O unit) — должна быть сначала продублирована где-нибудь в другом месте (в журнале), иначе восстановление после сбоя в общем случае невозможно.
Ну вот в IB так сделано, что подтверждение транзакции — это ИЗМЕНЕНИЕ ОДНОГО БИТА в файле БД. Достаточно атомарно? Получилось изменить бит — транзакция подтверждена раз и навсегда. Не получилось — не подтверждена. Больше ничего не надо. Даже если в ней были тыщи вставленных/измененных/удаленных записей.
Здравствуйте, Merle, Вы писали:
D>> И что тут плохого? M> M> Зависимость от клиента...
Сервер не должен заниматься самодеятельностью.
D>> Это просто альтернативная реализация, которая D>> имеет свои достоинства и недостатки. M> M> Вот именно эта реализация, в этом месте как раз M> имеет явный недостаток. M> В 99.9% случаев известно еще на этапе подготовки M> транзакции, что с ней делать в случае сбоя. И M> дергать клиента нет никакого смысла.
Только что проверил на Оракле. В случае любой ошибки (включая lock conflict) он ведет себя один в один с IB. Т.е. ошибка уходит к клиенту, а транзакция остается активной. И если предыдущие операторы транзакции отработали успешно, то только от клиента зависит, будет ли транзакция отменена полностью или подтверждена частично. И такое поведение полностью подтверждает мое понимание вещей. Единственный [мне известный] случай, когда Оракл (как и IB) откатывает транзакцию сам — это потеря соединения с клиентом.
Здравствуйте, dimitr, Вы писали:
M>> Зависимость от клиента... D>Сервер не должен заниматься самодеятельностью.
Это не самодеятельность, а прямая обязанность.
M>> Вот именно эта реализация, в этом месте как раз M>> имеет явный недостаток. M>> В 99.9% случаев известно еще на этапе подготовки M>> транзакции, что с ней делать в случае сбоя. И M>> дергать клиента нет никакого смысла.
D>Только что проверил на Оракле. В случае любой ошибки (включая lock conflict) он ведет себя один в один с IB. Т.е. ошибка уходит к клиенту, а транзакция остается активной. И если предыдущие операторы транзакции отработали успешно, то только от клиента зависит, будет ли транзакция отменена полностью или подтверждена частично.
Ты чего-то путаешь.
Если отправить на сервер вот такой батч:
begin trans
.....
commit trans
и внутри транзакции произойдет конфликт, то спрашивать клиента, оставляя подвешенной транзакцию, никто не будет.
Произойдет либо откат и старт новой транзакции, если клиент заранее попросил об этом, либо, по умолчанию, откат и сообщение об ошибке.
Транзакция активной не остается. Остается активным только подключение.
Естественно можно на клиенте инициировать транзакцию, а потом поочереди слать команды, тогда конечно все произойдет так, как ты описал.
Но обычно, в здравом уме так не делают... Хотя Оракл, хвастался, мол "теперь вы можете себе это позволить".
Понимаешь, даже обрыв не обязателен. Клиент может поменять пару записей и пойти пиво пить, а коннект при этом будет вполне себе поддерживаться... По таймауту его отрубать?
D>И такое поведение полностью подтверждает мое понимание вещей. Единственный [мне известный] случай, когда Оракл (как и IB) откатывает транзакцию сам — это потеря соединения с клиентом.
В IB, как я понимаю, нет явной возможности управлять транзакциями на сервере.
Иначе подобное решение с ожиданием решения клиента, что делать с транзакцией — очевидная архитектурная промашка.
M>Понимаешь, даже обрыв не обязателен. Клиент может поменять пару записей и пойти пиво пить, а коннект при этом будет вполне себе поддерживаться... По таймауту его отрубать?
Это уже вопрос архитектуры клиентского приложения. Оптимистическая/пессимистическая блокировка... Короткие/длинные транзакции... и т.п.
Здравствуйте, Merle, Вы писали:
M> Ты чего-то путаешь.
Да ну? ))
M> Если отправить на сервер вот такой батч: M>
M> begin trans
M> .....
M> commit trans
M>
M> и внутри транзакции произойдет конфликт, то спрашивать клиента, M> оставляя подвешенной транзакцию, никто не будет.
А тут клиент-то почти и не причем, получается.
M> Произойдет либо откат и старт новой транзакции, если клиент M> заранее попросил об этом, либо, по умолчанию, откат и M> сообщение об ошибке. M> Транзакция активной не остается. Остается активным только M> подключение.
Увы, я такими батчами мыслить не умею
M> Естественно можно на клиенте инициировать транзакцию, а потом M> поочереди слать команды, тогда конечно все произойдет так, M> как ты описал.
Именно об этом я и говорил.
M> Но обычно, в здравом уме так не делают... Хотя Оракл, хвастался, M> мол "теперь вы можете себе это позволить".
Давай не будем о здравом уме Ты пытаешся критиковать IB с точки зрения Оракла, который может запускать транзакции на стороне сервера. Я тебе отвечаю с точки зрения IB, который этого делать не умеет. Мы просто не можем прийти к консенсусу, по определению, ибо работаем с базой по-разному. То, что для тебя дикость — для меня единственный и вполне логичный подход к SQL-программированию, и наоборот.
M> Понимаешь, даже обрыв не обязателен. Клиент может поменять пару M> записей и пойти пиво пить, а коннект при этом будет вполне себе M> поддерживаться... По таймауту его отрубать?
Нет, конечно. Я просто хотел показать, что при управлении транзакциями с клиента оба сервера ведут себя абсолютно идентично. Что есть правильно. Поэтому никаких претензий к IB тут быть не может
M> В IB, как я понимаю, нет явной возможности управлять транзакциями M> на сервере.
Здравствуйте, dimitr, Вы писали:
D>А тут клиент-то почти и не причем, получается.
Так и должно быть...
M>> Естественно можно на клиенте инициировать транзакцию, а потом M>> поочереди слать команды, тогда конечно все произойдет так, M>> как ты описал.
D>Именно об этом я и говорил.
Ну понятно, IB по другому не умеет...
D>Давай не будем о здравом уме Ты пытаешся критиковать IB с точки зрения Оракла, который может запускать транзакции на стороне сервера.
Не, я пытаюсь критиковать IB с точки зрения зависимости от клиента.
D>То, что для тебя дикость — для меня единственный и вполне логичный подход к SQL-программированию, и наоборот.
Дык в том-то и дело, что подход не логичный.. Почему — понятно, единственный способ отрубить клиента отошедшего кофе попить — выход по таймауту, что не гарантирует отрубания клиентов, которые действительно делом заняты.
В данном случае, то, что IB чего-то неумеет — это недостаток, а не альтернативный подход...
Я, честно говоря, знал об этой особенности, но у меня вылетело напроч, именно поэтому я все никак не мог понять, что же IB клиента-то спрашивает постоянно...
D>Нет, конечно. Я просто хотел показать, что при управлении транзакциями с клиента оба сервера ведут себя абсолютно идентично.
Дык и MSSQL, при управлении транзакциями от клиента, точно так же себя ведет. По другому-то никак не получится.
D>Что есть правильно. Поэтому никаких претензий к IB тут быть не может
Может... Потому как неправильно это. Преимуществ у такого способа нет, а недостатков — масса, если уж рассуждать об этом, как об альтернативном подходе.
Здравствуйте, Merle, Вы писали:
КДВ>> как завершать транзакции, commit или rollback, в IB решает ТОЛЬКО клиентская часть. M>Ой. Вот явно чуствуется многоверсионность, сколько людей, столько и объяснений... M>А что есть здесь клиентская чать?
клиентская часть — это то, что коннектится к БД, пуляет запросы на сервер, и т.п. Грубо говоря —
gds32.dll (IB API).
КДВ>>И даже это не является причиной для того чтобы сервер пугался и кого-то там откатывал. M>О кей, давайте разберемся с самого начала. M>Допустим последовательная история транзакций приводит к конфликту. T1 пытается обновить запись, которую уже обновила T2, но при этом T2 еще не успела зафиксироваться. M>Далее возможное поведение T1: M>1. Ожидание на блокировке.
если T1 стартовала в режиме WAIT. Если нет (no wait) — T1 просто получит сообщение о том, что запись
обновлена другой транзакцией.
M>2. Откат T1 и новый старт.
нет. T1 сама будет решать — делать commit или rollback. В зависимости от уровня изолированности клиентская
часть программно может или подождать завершения T2 и сделать update снова, либо вызвать rollback.
M>3. Порождение новой версии данных с которой и работает T1, все разборки произойдут при commit'е (first wins, по классике, кто первый встал, того и тапки, кто не успел, того откатывают)
сразу видно человека, который поленился прочитать про многоверсионность
Не-committed версия записи может существовать ТОЛЬКО ОДНА. Т.е. T1 НЕ МОЖЕТ создать новую версию, пока
T2 не сделает commit или rollback. Всего то.
M>Кто принимает решение о дальнейшем развитии событий? Клиент? Не, не может быть..
А почему нет-то? Где тут ситуация, когда серверу надо самому рулить, объясни пожалуйста?
M>В случае любых сбоев, если конечно эт сбои не привели к физической порче диска. M>Тоесть любой сбой, во время любой операции должен быть обратимым и база должна сама прийти в согласованное состояние на момент непосредственно перед сбоем. (требование Durability из ACID так же не должно нарушаться. Что зафиксировано — не вырубишь топором)
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Romkin, Вы писали:
R>>Брр... Многое зависит от параметров транзакции. В любм случае при фиксации Т2 на клиентскую часть, породившую Т1 пойдет сообщение о deadlock, что решит клиент — его дело. M>А дедлок-то тут причем? Тем дальше в лес, тем толще партизаны. M>Насколько я понимаю, возможно наличие только одной незафиксированной версии данных. Из твоих слов можно заключить, что даже если T1 ждет на блокировке, и таки дожидается, когда T2 зафиксируется, то T1 все равно откатят?
не откатят, а T1 получит сообщение о невозможности сделать update (exception).
Т.е. тут ты все правильно понял. В IB существует в общем случае только один конфликт — попытка
update/delete одной записи двумя конкурирующими транзакциями. Независимо от режима wait
или nowait, такая ситуация называется "deadlock". Не совсем прозрачно, но так получилось.
По крайней мере в каждой ситуации к слову "deadlock" добавляется пояснение с описанием ситуации.
"update conflict on nowait transaction", и т.п.
M>Тоесть дожидаться имеет смысл только в надежде на то, что T2 обломается по своим причинам?
R>>Может-может M>Не, клиент тут ничего не может, а вот TM определяет, что транзакции конфликтны и поступает в соответствии с рекомендациями клиента.
Это вопрос взглядов. IB придерживается схемы, когда именно приложение (!) определяет какие
именно операторы входят в транзакцию. Т.е. только клиент может стартовать транзакцию, и только
клиент может завершить ее тем или иным способом, независимо от тех конфликтов, которые произошли на сервере.
Это потому, что в IB целостность данных проверяется на ходу, именно при выполнении insert/update/delete,
а не отложенно, при commit, как например в MS SQL.
Т.е. в IB commit можно сказать что ничего не делает, просто переводит состояние (!) транзакции из active
в commit и все. а видимость-невидимость версий записей определяется по состоянию транзакций, которые эти
версии создавали.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Romkin, Вы писали: R>>Что значит "повисает"? Транзакция остается транзакцией — клиент ее открыл, вкатывает данные, в конце либо commit либо rollback. Если считать, что транзакция от старта до окончания повисает, тогда да, висит S>Как-то странно это. Ну вот открыл я транзакцию. Работаю-работаю. С клиента. Возникает у меня этот дедлок. И что, я после этого могу продолжать работу? Или сделать commit?
ага. или rollback — как его высочеству ПРИЛОЖЕНИЮ будет угодно.
S>Просто в рамках MS SQL к моменту deadlock кто-то просто должен сделать rollback.
Да просто потому, что у MS SQL изменения в транзакции применяются в момент COMMIT!
А у IB — в момент выполнения этих самых insert/update/delete. Вот и вся разница.
Поэтому MS SQL НЕ МОЖЕТ ничего другого сделать кроме как автоматизированно
выполнить rollback. А в IB — клиент сам может решить, что ему делать.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, dimitr, Вы писали:
M>Ведь в 99.9% случаев уже на этапе подготовки транзакции известно, в каком месте ошибка должна приводить к откату, а в каком нет. И вообще как с этой транзакцией поступать в случае сбоя. Для этого вовсе не надо дергать клиента в момент конфликта, никакой дополнительной информации от сервера он не получит.
не надо перекладывать идеологию конкретной реализации MS SQL на другие сервера. Не надо.
Ты еще скажи, что в одном коннекте нельзя стартовать несколько транзакций одновременно.
MS SQL этого не умеет? Ну и пусть. IB умеет. Это не плюс и не минус, просто другая
схема обработки транзакций.
D>>Не обязательно. Моя транзакция может работать в режиме изоляции "read-committed" и, получив отлуп и перечитав изменения, уже _закоммиченные_ моим конкурентом, принять решение о повторной записи. M>Ну правильно. Это и есть откат и новый старт транзакции по новой версии данных.
Чего-чего? Какой откат? read committed пока не кончилась живет без "рестартов". И видит чужие
committed изменения.
КДВ>нет. T1 сама будет решать — делать commit или rollback.
Тоесть клиент?
M>>3. Порождение новой версии данных с которой и работает T1, все разборки произойдут при commit'е (first wins, по классике, кто первый встал, того и тапки, кто не успел, того откатывают)
КДВ>сразу видно человека, который поленился прочитать про многоверсионность
Не, если уж мы боремся за чистоту формулировок, то видно человека, который поленился почитать про многоверсионность в IB
КДВ>Не-committed версия записи может существовать ТОЛЬКО ОДНА. Т.е. T1 НЕ МОЖЕТ создать новую версию, пока T2 не сделает commit или rollback. Всего то.
Только в IB.
В формальной теории нет таких ограничений, почитать можно например тут: Concurrency Control and Recovery in Database Systems By
Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman
КДВ>А почему нет-то? Где тут ситуация, когда серверу надо самому рулить, объясни пожалуйста?
Ну просто непонятнго было зачем клиента дергать в случае ошибки, если всю информацию, о том, что делать с транзакцией после сбоя, можно было отослать вместе с самой транзакцией ище до ее старта.
Но похоже в IB просто нет такой возможности..
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, dimitr, Вы писали:
D>>Не угадал. Инициация исключения и доставка оного на клиентскую сторону. И все. После чего транзакция может быть подтверждена частично или произведен откат. M>Вот здесь вот явная зависимость от клиента... А если в момент доставки эксепшена клиент отвалился, то по такой схеме все становится очень грустно. Транзакция повисает, в нее упираютя другие транзакции, которым нужны данные уже захваченные ей, и так далее..
чего??? опять игнорируем всю информацию, которую дали раньше. в IB нет блокировок, ВООБЩЕ.
Если в момент exception клиент отвалился то это означает:
1. действия, которые привели к exception, НЕ ПРОШЛИ. просто никуда не записались
2. "зависший" клиент будет обнаружен, и сервер автоматически переведет состояние
его транзакций в rollback
3. все, кто будет читать/модифицировать версии, созданные "отвалившимися" транзакциями,
уберут эти изменения как мусор.
Все.
D>>Или ты предлагаешь при конфликте делать рестарт транзакции и накат всех изменений, предшествующих конфликту? Интересно узнать, какая СУБД так поступает... M>Oracle Со многими оговорками и нюансами, понятное дело, но да, примерно так. Да и вообще, классический версионник, по теории, примерно так и должен поступать. И это достаточно логично и оправдано.
Oracle не классический версионник. Версионность в нем введена частично.
M>>> Кто принимает решение о дальнейшем развитии событий? Клиент? Не, не может быть.. D>>Еще как может M>Ну вот не верится мне, что это удачная идея....
Здравствуйте, Merle, Вы писали:
M>Естественно можно на клиенте инициировать транзакцию, а потом поочереди слать команды, тогда конечно все произойдет так, как ты описал. M>Но обычно, в здравом уме так не делают... Хотя Оракл, хвастался, мол "теперь вы можете себе это позволить".
В здравом уме при интерактивной работе клиента с данными никто не отправляет на сервер никаких пакетов.
Ты опять игнорируешь все что тебе пишут. IB сам не стартует и не завершает транзакций на сервере. Просто
не умеет. инициирует работу с транзакциями только клиент.
M>Понимаешь, даже обрыв не обязателен. Клиент может поменять пару записей и пойти пиво пить, а коннект при этом будет вполне себе поддерживаться... По таймауту его отрубать?
это проблемы клиентских приложений и длинных транзакций.
D>>И такое поведение полностью подтверждает мое понимание вещей. Единственный [мне известный] случай, когда Оракл (как и IB) откатывает транзакцию сам — это потеря соединения с клиентом. M>В IB, как я понимаю, нет явной возможности управлять транзакциями на сервере.
наконец-то догадался.
M>Иначе подобное решение с ожиданием решения клиента, что делать с транзакцией — очевидная архитектурная промашка.
Здравствуйте, Кузьменко Д.В., Вы писали:
КДВ>Это вопрос взглядов. IB придерживается схемы, когда именно приложение (!) определяет какие КДВ>именно операторы входят в транзакцию.
Это везде так, вопрос на каком этапе это происходит. IB — приходится дергать клиента, а другие сервера умеют и так и так.
И по вполне очевидным причинам даже для версионника это засада, хотя и меньшая чем для блокировочника.
КДВ>Это потому, что в IB целостность данных проверяется на ходу, именно при выполнении insert/update/delete, КДВ>а не отложенно, при commit, как например в MS SQL.
Не поверишь, целостность данных здесь вообще не причем. и MSSQL и большинство других серверов тоже проверяют ее на каждый оператор.
Отложенная проверка (Differed Referential integrity — DRI) Возможна в Oracle и в Informix, на сколько мне известно, но опять же опционально.
Здравствуйте, Кузьменко Д.В., Вы писали:
M>>Естественно можно на клиенте инициировать транзакцию, а потом поочереди слать команды, тогда конечно все произойдет так, как ты описал. M>>Но обычно, в здравом уме так не делают... Хотя Оракл, хвастался, мол "теперь вы можете себе это позволить".
КДВ>В здравом уме при интерактивной работе клиента с данными никто не отправляет на сервер никаких пакетов.
Ага, по байтно шлют..
КДВ>Ты опять игнорируешь все что тебе пишут.
Нет, просто ты не внимательно читаешь... Я здесь писал про другие сервера, а не про IB.
КДВ>IB сам не стартует и не завершает транзакций на сервере. Просто
не умеет. инициирует работу с транзакциями только клиент.
Оф корс. Вот это-то мне и не нравится.
КДВ>это проблемы клиентских приложений и длинных транзакций.
А транзакции на сервере избавляют клиента от этой головной боли раз и на всегда.
Здравствуйте, Кузьменко Д.В., Вы писали:
КДВ>чего??? опять игнорируем всю информацию, которую дали раньше. в IB нет блокировок, ВООБЩЕ.
Хорошо, переформулирую, нет возможности обновить данные уже обновленные другой транзакцией, если эта другая транзакция не зафиксирована.
Возможно я несколько не понятно излагаю, грешен...
КДВ>1. действия, которые привели к exception, НЕ ПРОШЛИ. просто никуда не записались КДВ>2. "зависший" клиент будет обнаружен, и сервер автоматически переведет состояние КДВ>его транзакций в rollback
И сколько времени пройдет, пока это обнаружится? Это секунды, а секунды — это очень много.
КДВ>Это просто другая идеология.
Обладающая очевидным недостатком..
Здравствуйте, Merle, Вы писали:
КДВ>>1. действия, которые привели к exception, НЕ ПРОШЛИ. просто никуда не записались КДВ>>2. "зависший" клиент будет обнаружен, и сервер автоматически переведет состояние КДВ>>его транзакций в rollback M>И сколько времени пройдет, пока это обнаружится? Это секунды, а секунды — это очень много.
КДВ>>Это просто другая идеология. M>Обладающая очевидным недостатком..
Возможно. Но, кажется, на Linux отваливание клиента обнаруживается системой практически сразу, да вроде и на win это сделано. Не пробовал, правда.
Дело в том, что как правило обновления не особо-то и пересекаются, в отличие от чтений. Да и программировать рекомендуется короткие транзакции, а не держать их как можно дольше.
Простая система — на сервере нет управления транзакциями.
R>Возможно. Но, кажется, на Linux отваливание клиента обнаруживается системой практически сразу, да вроде и на win это сделано.
Это естественным образом обнаруживается СРАЗУ, если идет обмен клиент-сервер. Например, если сделал запрос — получаешь данные со всей возможной скростью — и связь порвалась — то сервер это сразу обнаружит.
"Подвиснуть" дохлая трнзакция может только при затишье, когда сервер ничего не ждет от клиента и ничего ему писать не собирается. Реально это довольно редкий случай. Но бывает. Dialup например. Но от этого уже никакая архитектура не спасет.
Здравствуйте, Кузьменко Д.В., Вы писали:
КДВ>не надо перекладывать идеологию конкретной реализации MS SQL на другие сервера. Не надо.
Это не идеология, это уже функциональность. С MSSQL'ем и с Oracle'ом можно работать и так и так. С IB, только через клиента.
Та самая "Идеология" в других серверах реализована ни чуть не хуже, только все почему-то предпочитают управлять транзакциями на сервере.
И если бы в IB была такая возможность, то ей бы тоже пользовались, а с клиента управляли бы только в очень исключительных случаях.
Не надо все на идеологию списывать.
КДВ>Чего-чего? Какой откат? read committed пока не кончилась живет без "рестартов". И видит чужие committed изменения.
Да, именно так. Поэтому при RC она может просто подождать, однако при SS так уже не получится.
Здравствуйте, Igor Trofimov, Вы писали:
КДВ>>Ты еще скажи, что в одном коннекте нельзя стартовать несколько транзакций одновременно. КДВ>>MS SQL этого не умеет? Ну и пусть. IB умеет.
iT>Говорят еще более страшную вещь — в одном коннекте нельзя одновременно два запроса фетчить. Если я правильно понял... Это ж вообще ужас.
Точнее говоря, это следствие того, что это нельзя делать в одной транзакции.
С другой стороны, живут же люди как-то. И даже под это философскую базу подводят.
PS. Firebird .Net Provider, по (почти) непонятной причине, сделан так же.
Здравствуйте, Igor Trofimov, Вы писали:
КДВ>>Ты еще скажи, что в одном коннекте нельзя стартовать несколько транзакций одновременно. КДВ>>MS SQL этого не умеет? Ну и пусть. IB умеет.
iT>Говорят еще более страшную вещь — в одном коннекте нельзя одновременно два запроса фетчить. Если я правильно понял... Это ж вообще ужас.
Это все проблемы клиента, а точнее провайдера... Серверу пофигу, он железный. Ему как передадут, так он и выполнит.
Здравствуйте, Кузьменко Д.В., Вы писали: КДВ>не надо перекладывать идеологию конкретной реализации MS SQL на другие сервера. Не надо. КДВ>Ты еще скажи, что в одном коннекте нельзя стартовать несколько транзакций одновременно. КДВ>MS SQL этого не умеет? Ну и пусть. IB умеет. Это не плюс и не минус, просто другая КДВ>схема обработки транзакций.
Интересно. А как сервер узнает, к какой транзакции относится очередной стейтмент?
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Igor Trofimov, Вы писали: iT>"Подвиснуть" дохлая трнзакция может только при затишье, когда сервер ничего не ждет от клиента и ничего ему писать не собирается. Реально это довольно редкий случай. Но бывает. Dialup например. Но от этого уже никакая архитектура не спасет.
Именно поэтому MS SQL делает keepalive все время. Благодаря этому внезапная смерть клиента посреди длиннного апдейт-запроса приводит к немедленному роллбэку.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Привет, Sinclair!
Вы пишешь 14 ноября 2003:
КДВ>> не надо перекладывать идеологию конкретной реализации MS SQL на другие сервера. Не надо. КДВ>> Ты еще скажи, что в одном коннекте нельзя стартовать несколько транзакций одновременно. КДВ>> MS SQL этого не умеет? Ну и пусть. IB умеет. Это не плюс и не минус, просто другая КДВ>> схема обработки транзакций. S> Интересно. А как сервер узнает, к какой транзакции относится очередной стейтмент?
Каждый стейтмент выполняется в контексте определённой транзакции.
Для этого клиент при вызове фунции API, типа isc_dsql_execute2(),
должен в качестве входного параметра передать хендл транзакции.
S>Именно поэтому MS SQL делает keepalive все время. Благодаря этому внезапная смерть клиента посреди длиннного апдейт-запроса приводит к немедленному роллбэку.
Ну дык и в IB интервалы проверки на живость клиента настраиваются... Но на медленных ненадежных каналах слишком частые интервалы — плохо, а значит — вероятны более длинные подвисания дохлых коннектов.. В любом сервере.
Здравствуйте, Igor Trofimov, Вы писали:
S>>Именно поэтому MS SQL делает keepalive все время. Благодаря этому внезапная смерть клиента посреди длиннного апдейт-запроса приводит к немедленному роллбэку.
iT>Ну дык и в IB интервалы проверки на живость клиента настраиваются... Но на медленных ненадежных каналах слишком частые интервалы — плохо, а значит — вероятны более длинные подвисания дохлых коннектов.. В любом сервере.
И не только там, keep alive настраивается и в winNT и в Linux, ничего не мешает настроить так, чтобы выяснялось это мгновенно (ну почти)
А если еще учесть, что самый неудобный режим для IB это конкурентное и непрерывное обновление одних и тех же записей, то можно заключить, думаю, что БД строить надо так, чтобы одна и та же запись обновлялась пореже, и в этом случае повисание транзакции из-за отваливания клиента не так уж и критично.
Здравствуйте, Merle, Вы писали:
M> Та самая "Идеология" в других серверах реализована M> ни чуть не хуже, только все почему-то предпочитают M> управлять транзакциями на сервере.
Стоп. Не надо говорить за всех. Если они не умеют мыслить по другому — это их проблемы. Я знаю массу людей и приложений, которые не используют серверное управление транзакциями в Оракле. И для них это _нормально_.
M> И если бы в IB была такая возможность, то ей бы тоже M> пользовались, а с клиента управляли бы только в очень M> исключительных случаях.
См. выше. Мое понимание прямо противоположное. Принцип программирования типа "запустил команду и забыл, а там хоть трава не расти" мне чужд. Транзакция — это понятие бизнес-логики. А ей управляет только клиент (или сервер приложений). Все остальное — от лукавого.
Здравствуйте, dimitr, Вы писали:
D>Стоп. Не надо говорить за всех. Если они не умеют мыслить по другому — это их проблемы. Я знаю массу людей и приложений, которые не используют серверное управление транзакциями в Оракле. И для них это _нормально_.
Это оправдано, в рамках очень хорошо прописанного среднего звена, которое, к слову, в оракле очень не плохо реализуется в самом сервере.
Так что тут еще надо подумать, что считать управлением транзакций на сервере и на клиенте.
D>См. выше. Мое понимание прямо противоположное. Принцип программирования типа "запустил команду и забыл, а там хоть трава не расти" мне чужд.
Смотря что понимать под "запустил и забыл".
В чем смысл бегать к клиенту и спрашивать "что делать?" в случае ошибки. "Что делать" клиент может сказать в момент старта транзакции. А сервер придет к клиенту и скажет "Ну вот, сделал, дальше че?".
Вот собственно и все разница, но второй вариант череват гораздо меньшими ошибками..
Здравствуйте, Merle, Вы писали:
D>>См. выше. Мое понимание прямо противоположное. Принцип программирования типа "запустил команду и забыл, а там хоть трава не расти" мне чужд. M>Смотря что понимать под "запустил и забыл". M>В чем смысл бегать к клиенту и спрашивать "что делать?" в случае ошибки. "Что делать" клиент может сказать в M> момент старта транзакции.
"Значит так, сервер, сейчас я запущу транзакцию. Потом буду передавать кучу инсертов.
Ежели на каком инсерте выпадет Key violation, то ты не пугайся, это вполне могёт быть.
Ты тогда вместо инсерта запусти апдейт — типа такая запись уже есть, мы её просто обновим.
Но если и при апдейте вылезет какой эксепшн, то тут надо подумать! Если это остатки товаров
получились отрицательные, то ты, сервер, запись эту всё-таки вставь, но в поле "Проведён" выставь
нолик. А вот ежели в записи Клиент указан какой несуществующий, тогда всё, сливай воду.
Пусть админ разбирается. Наверное...
Ну а если ещё что — вываливай окошко с подробным сообщением об ошибке и ... и сам думай, что делать,
потому как никто это окошко не увидит.
Ну, что? Готов? Начинаю:
BeginTransaction() insert(...); insert(...); insert(...); insert(...);"
M>А сервер придет к клиенту и скажет "Ну вот, сделал, дальше че?". M>Вот собственно и все разница, но второй вариант череват гораздо меньшими ошибками..
Здравствуйте, Merle, Вы писали:
M> В чем смысл бегать к клиенту и спрашивать M> "что делать?" в случае ошибки. "Что делать" M> клиент может сказать в момент старта транзакции. M> А сервер придет к клиенту и скажет "Ну вот, сделал, M> дальше че?".
А клиента в этот момент уже нет. Снесли его по ctrl-alt-del, не дождавшись ответа от сервера, аккурат перед возвратом результата от оного. А транзакция уже подтверждена сервером. Спрашивается — что делали, зачем, для кого?...
Я допускаю, что в каких-то случаях старт и подтверждение транзакции на стороне сервера действительно предпочтительнее. Но считать это нормальным режимом работы не стоит. IMHO, разумеется.
P.S. Что-то эта ветка ушла далековато от своих истоков...
Здравствуйте, dimitr, Вы писали:
D>А клиента в этот момент уже нет. Снесли его по ctrl-alt-del, не дождавшись ответа от сервера, аккурат перед возвратом результата от оного.
И не надо. В том-то и фишка, что нафиг клиент не нужен, если транзакция стартовала. Зависимости от клиента нет.
D>А транзакция уже подтверждена сервером. Спрашивается — что делали, зачем, для кого?...
Транзакция действие атомарное. БД — это хранилище данных, транзакции переводят данные из одного состояния в другое, по принципу "все или ничего". И если в процессе перевода клиент отвалится, то транзакция от этого страдать не должна.
Если же, в случае ошибки, транзакция должна ходить к клиенту и спрашивать, что делать, то это, как минимум, черевато потерями производительности.
Для версионника конечно меньшими, чем для блокировочника, но тем не менее и версионнику без подобных хождений жилось бы легче.
D>Я допускаю, что в каких-то случаях старт и подтверждение транзакции на стороне сервера действительно предпочтительнее. Но считать это нормальным режимом работы не стоит. IMHO, разумеется.
Стоит. Это именно и есть нормальный режим работы во всех СУБД, которые это поддерживают.
D>P.S. Что-то эта ветка ушла далековато от своих истоков...
Действительно, пора завязывать.
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Не. Это проблемы сервера. AS>Вот в Юконе это дело порешали...
Не в Юконе, а в ADO.Net 2.0 и Юконе, но в сервере там изменения минимальны, на сколько я понял, просто чтобы провайдеру чуть проще было.
Здравствуйте, Alex.Che, Вы писали: AC>Каждый стейтмент выполняется в контексте определённой транзакции.
В принципе, я не вижу никакого логического преимущества в возможности стартовать несколько транзакций в одном соединении AC>Для этого клиент при вызове фунции API, типа isc_dsql_execute2(), AC>должен в качестве входного параметра передать хендл транзакции.
потому как везде при вызове функций API передается хендл заранее подготовленного контекста.
Это может быть connection, connection+transaction, connection+transaction+preparedstatement...
Техническая разница, конечно же, в производительности. Чем гранулярнее контексты, тем дешевле отщепить еще один.
Максимально быстро получается работать с самым полным контекстом (prepared statement).
Когда мы получаем новый prepared statement, можно взять готовый контекст соединения и транзакции.
Если мы хотим получить новую транзакцию, параллельную существущей, то в MS SQL придется создать новое соединение, а в IB, значить, можно готовое использовать. Интересно, велик ли выигрыш?
... << RSDN@Home 1.1.0 stable >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
хъ
M>Не в Юконе, а в ADO.Net 2.0 и Юконе, но в сервере там изменения минимальны, на сколько я понял, просто чтобы провайдеру чуть проще было.
Из чего ты это понял?
SQL Server "Yukon" Beta 1 extends the support for multiple active result sets (MARS) in applications accessing the database engine. In earlier versions of SQL Server, database applications could not maintain multiple active statements on a connection when using default result sets. The application had to process or cancel all result sets from one batch before it could execute any other batch on that connection. SQL Server "Yukon" introduces new attributes that allow applications to have more than one pending request per connection, in particular, to have more than one active default result set per connection.
SQL Server "Yukon" Beta 1 introduces a new feature called multiple active result sets (MARS). MARS allows client drivers to have more than one pending request per connection.
Здравствуйте, Alexey Shirshov, Вы писали:
AS>Из чего ты это понял?
Из того, что дядька про PDC рассказывал.. Вообщем смотреть надобно, ручками ковыряться.
AS>SQL Server "Yukon" Beta 1 extends the support for multiple active result sets (MARS) in applications accessing the database engine. In earlier versions of SQL Server, database applications could not maintain multiple active statements on a connection when using default result sets. The application had to process or cancel all result sets from one batch before it could execute any other batch on that connection. SQL Server "Yukon" introduces new attributes that allow applications to have more than one pending request per connection, in particular, to have more than one active default result set per connection.
AS>
AS>SQL Server "Yukon" Beta 1 introduces a new feature called multiple active result sets (MARS). MARS allows client drivers to have more than one pending request per connection.
Потрясающе, это выдающееся достижение! Кто-бы мог подумать?!
Несколько активных курсоров в одном соединении!
Теперь осталось дождаться ещё возможности открывать несколько транзакций в одном коннекте.
Оказывается, один коннект — одна транзакция — один активный курсор — это не философия такая работы с БД,
а просто сделать по другому не получалось.
Здравствуйте, Alexey Shirshov, Вы писали:
AS>>>Из чего ты это понял? M>>Из того, что дядька про PDC рассказывал.. AS>О! Тут какой-то дядка завелся?
Да не тут, в Майкрософте...
Мы уже победили, просто это еще не так заметно...
как завершать транзакции, commit или rollback, в IB решает ТОЛЬКО клиентская часть. Сервер никогда не занимается самодеятельностью. Потому что в этом нет никакой необходимости. Собственно, в IB конфликтуют только транзакции, которые пытаются обновить одну и ту же запись одновременно. И даже это не является причиной для того чтобы сервер пугался и кого-то там откатывал.
