Поделитесь пожалуйста толковой ссылкой, на то как устроен механизм восстановления после сбоев в 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 определяет, что транзакции конфликтны и поступает в соответствии с рекомендациями клиента.
Мы уже победили, просто это еще не так заметно...
как завершать транзакции, commit или rollback, в IB решает ТОЛЬКО клиентская часть. Сервер никогда не занимается самодеятельностью. Потому что в этом нет никакой необходимости. Собственно, в IB конфликтуют только транзакции, которые пытаются обновить одну и ту же запись одновременно. И даже это не является причиной для того чтобы сервер пугался и кого-то там откатывал.
