Dima T1. Картинка как называется? Если SQLite lock transitions, то у меня она внизу стр. 187.

у тебя таки третье издание?

авторписатель может остановиться между двумя операторами $select$

--
та ну.
писатель может успеть сработать между двумя операторами $select$

меня этот писатель вообще раздражает

авторИ, как вскоре будет понятно,
другое соединение может успеть сработать между двумя операторами $select$
и изменить БД.

Dima Tсоединение пробует взять установить блокировку для чтения на байте ожидания.
ИМХО тут автор попытался кратко описать устройство механизма блокировок, но у него это не получилось, а получились непонятные обрывки подробностей.

угу, я лелеял надежду, что ты понял что там написано, пока продирался через эту ахинею.

надо еще долго перечитывать


автор.;----------7777

.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p147_1.png}
.;-
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p147_2.png}
.;-
Собственно, разработка функции $spam\_mother\_in\_law()$ остается как упражнение для читателя.
.^
Функция $step()$ должна получить блокировку SHARED в БД, чтобы выполнить оператор $select$.
Предположим, с этой БД есть еще активное пишущее соединение. Тогда обычно функция $step()$ возвращает
SQLITE\_BUSY. Однако в нашем случае это не так.
Здесть менеджер страниц (тот из них, который обращается за блокировкой) вместо этого вызывает функцию $busy()$,
так как она была зарегистрирована в качестве обработчика занятости.
$busy()$ увеличивает счетчик $counter$, посылает теще сотню случайных писем
из своей папки со спамом и возвращает 1. Менеджер страниц интерпретирует её как true (сигнал продолжать захватывать блокировку)
и повторяет попытку получить
блокировку SHARED.
На этот раз, $busy()$ возвращает 0, который воспринимается как false.
Тогда менеджер страниц, вместо повторения захвата блокировки, возвращает код SQLITE\_BUSY, которым
закончится работа функции $step()$.
.^
Разрабатывать обработчик занятовсти просто для ожидания (чтобы убить время) нет нужды.
Он уже есть в программный интерфейс \nm. Это функция, которая просто засыпает на заданный период времени для ожидания
блокировки. Её название $sqlite3\_busy\_timeout()$ и поддерживается библиотеками некоторых языков расширений.
По существу можно просто сказать 'засни на 10 секунд, если не сможешь получить блокировку'
и менеджер страниц сделает это. Он подождет 10 секунд, и затем, если не сможет получить блокировку, вернет SQLITE\_BUSY.


.;3 Using the Right Transaction
.3 Правильное Использование Транзакций
.^
Ещё раз пересмотрим предыдущий пример, но теперь в нем заменим оператор $select$, на оператор $update$.
Что на деле будет означать SQLITE\_BUSY?
После применения $select$ это просто значит: 'Я не могу получить блокировку SHARED'.
А что это значит в случае $update$?
На деле, это неизвестно.
SQLITE\_BUSY может означать, что соединение не смогло получить блокировку SHARED, в связи
с наличием другого пишущего соединения в состоянии PENDING.
Это может означать, что соединение, получив SHARED, не может получить RESERVED.
Отличие в том, что не известно состояние БД или состояние рассматриваемого соединения.
SQLITE\_BUSY для запросов на запись полностью неопределен в
режиме автофиксации.
Итак, что же теперь делать дальше?
Надо ли вызывать $step()$ снова и снова, пока оператор не выполнится?
.^
над этим надо подумать.
Предположим, попытка получить блокировку SHARED, а не RESERVED,
закончилась SQLITE\_BUSY и теперь соединение удерживает состояние
RESERVED.

.:++++ Suppose SQLITE_BUSY was the result of you getting a SHARED lock but not RESERVED,
.:++++ and now you are holding up a connection in RESERVED from getting to EXCLUSIVE.

Напомним, состояние БД - не известно.

И нахрапистая попытка любой ценой выполнять свою транзакцию не обязательно завершится удачей,
и в рассматриваемом соединении, и в любом другом.
Попытки вызова $step()$ заведут в тупик -- в задницу соединения в состоянии RESERVED,
и, если никто из двоих не сбойнет, к клинчу.
.= Замечание
\nm пытается избежать клинча в конкретно этом сценарии, игнорируя вызов обработчика занятости (busy handler),
.x обработчик занятости
.x busy handler
.;++++
Обработчик занятости соединения в состоянии SHARED не вызывается, если предполагается, что
он будет мешать завершиться соединению в состоянии RESERVED.
.;++++ However, it is up to the code to get the hint.
Приложение может просто продолжать вызывать $step()$, и, в этом случае,
ничто не спасет \nm
.=
Поэтому запрос на запись надо начинать с $begin immediate$.
По крайней мере, при получении ответа SQLITE\_BUSY, будет известно состояние соединения.
Пишущее соединение сможет повторять свои попытки без блокирования другого соединения.
И известно, что при достижении успеха, пишущее соединение переходит в состояние RESERVED.
.;Now you can use brute force if you have to because you are the one in the right.
Теперь можно делать что угодно.
С другой стороны, $begin immediate$ является гарантией что не придется иметь дела с условиями занятости вообще.
Но при этом надо помнить, что пишущее соединение находится в состоянии EXCLUSIVE, которое
снижает эффективность многократных соединений, по сравнению с работой в состоянием RESERVED.
.=
.4 Блокировки и Сетевая Файловая Система
.^
Теперь можно иметь хорошее представление о трудностях
использования файла ДБ через сетевую файловую систему (в расшаренном каталоге).
\nm поддерживает многократные соединения размещая файл блокировки в файловой системе.
Очень важно, чтобы этот файл и размещался и удалялся в правильные моменты времени.
Корректность управления блокировками многократных соединения у \nm полностью зависит от файловой системы.
Под Unix \nm использует POSIX advisory locks, а под Windows - OS X и системные вызовы $LockFile()$ $LockFileEx()$$UnlockFile()$.
Эти стандартные системные вызовы корректно работают в несетевой файловой системе.
Сетевая файловая система эмулирует работу обычной. И, к сожалению, в некоторых реализациях эта
эмуляция не всегда корректна. Даже в случае корректной работы сетевой файловой системы
остаются поводы для размышлений.
.^
Возьмем к примеру NFS. Это отличная сетевая файловая система.
Однако, исходная реализация NFS имеет известные ошибки и, в некоторых случаях, не имеет реализованніх блокировок.
Это означает серьезную проблему для \nm. Без блокировок два соединения могут перейти в состояние EXCLUSIVE
на одной ДБ и в одно время, что приведет к определенным нарушениям целостности.
Это не проблема NFS вообще, это проблема некоторых её реализаций.
Благодаря последним реализациям NFS эти трудности преодолены и некоторые из них (такие, которые используются в Sun)
вполне работоспособны.
.; в виндюках это не надо



.;2 +m1-5-6 Code
.2 +m1-5-6 Прикладные Программы
.^
Наконец, получена хорошая картина для программного интерфейса, транзакций и блокировок.
Чтобы покончить с этим, рассмотрим все это с точки зрения прикладной программы и
рассмотрим пару сценариев, которые было бы желательно обсудить.


.;3 Using Multiple Connections
.3 Использование Нескольких Соединений
.^
Опытные программисты могут написать приложение, использующее несколько соединений.
Классический пример: одно соединение проходит по таблице в то время, как другое изменяет её.
Такие приожения могут приводить к трудностям в работе \nm, поэтому их надо
аккуратно обдумывать.
Рассмотрим пример:
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p149_1.png}
.;-
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p149_2.png}
.;-
.; we bet
Можно спорить, что здесь легко указать трудность.
Находясь в цикле $while$, соединение $c2$ выполняет обновления таблицы, в то время как
соединение $c1$ имеет блокировку в состоянии SHARED.
Эта блокировка не будет освобождена до финализации оператора $stmt$ после цикла.
Таким образом, нет никакой возможности выполнить запрос обновления БД внутри цикла.
Либо $c2.exec()$ будет тихо сбоить, либо, в случае обработчиков занятости, они будут просто тормозить приложение.
Более правильная версия этого примера должна использовать одно соединения и выполнять запросы в рамках
транзакции $begin immediate$. Новую версию приводим ниже:

.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p149_3.png}
.;-
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p150_1.png}
.;-
.^
В подобных случаях надо использовать операторы из одного соединения для запросов чтения и записи.
Тогда не зачем беспокоиться о трудностях, вызываемых блокировками БД.
Но, как оказывается, этот конкретный пример остается нерабочим.
.;----- ????
Процесс блокирование при чтение таблицы одним оператором и редактирование её другим
имеет дополнительную тонкость, которую тоже надо знать.
Сейчас она будет раскрыта.
.;3 The Importance of Finalizing
.3 Важность Финализации
.^
Обычной промашкой в обработке оператора $select$ является непонимание того,
что блокировка SHARED не обязательно освобождается при вызове фунгкции $finalize()$ ( или $reset()$),
более того, обычно не освобождается.
.; +++++ переспросить
Рассмотрим пример:
.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p150_2.png}
.;-
Хотя так программы на практике не пишут, это можно написать случайно,
просто потому, что так можно сделать.
.;++++ you might end up doing it anyway by accident simply because you can get away with it.
Эквивалент этого примера, написанный с помощью программного интерфейса C,
будет на деле работать. Даже если не вызвать $finalize()$, второе соединение изменит БД
безо всяких проблем. Прежде чем сказать почему, взглянем на следующий пример:


.b
.;-
\includegraphics[width=1.00\textwidth]{./m6_pics/p150_3.png}
.;-
Предположем в таблице $episodes$ есть 100 запией. Приложение прошло только
три из них. Что случиться теперь?
Вторе приложение получит SQLITE\_BUSY.
.^
В предыдущем примере, \nm освобождает блокировку SHARED, когда оператор
достигает окончания отношение результата.
То есть, в момент последнего вызова $step()$, на котором программный интерфейс C возвращает SQLITE\_DONE,
VDBE встреить инструкцию $Close$ и \nm закроет курсор и сбросит блокировку SHARED.
То есть, $c2$ будет иметь возможность выполнить свой $insert$
.; не было инсерта был апдайет ------
хотя $c1$ еще не вызвал $finalize()$.
.^
Во втором случае, оператор $select$ не достиг последней записи из отношения результата.
Поэтому следующий выхов $step()$ должен вернуть SQLITE\_RESULT,
что означает наличие непрочитанных записей в отношении результате, это же означает,
что блокировка SHARED остается.
Значит, $c2$ не может из - за неё выполнить $insert$.
.; на деле $update$
.^
Мораль этой истории в том, что не надо делать все, что можно. Вызовать $finalize()$
или $reset()$ перед запросами на редактирование нужно всегда, когда есть другие соединения.
Также хорошо бы помнить, что $step()$ и $finalize()$ в режиме автофиксации
более или менее ограничивают транщакции и блокировки.
Они начинают и заканивают транзакции. Они начинают и освобождают блокировки.

.; ++++++
.; The other thing to remember is that in autocommit mode step() and finalize()
.; are more or less transaction and lock boundaries
Нужно очень аккуратно работать в другом соединении между этими двумя функциями.



.3 Режим Разделяемого Кэша
.;3 Shared Cache Mode
.^
Теперь, когда все понятно про правила работы конкурирующих соединений, настало время для некоторого усложенния.
\nm имеет еще одну модель для конкурирующих соединений, которая называется режим разделяемого кэша.
Она относится (регулирует / позволяет??) к работе соединений внутри отдельных нитей.
.;++++
.^
В этом режиме нити могут создавать несколько соединений, которые сообща используют (разделяют) один и тот же самый кэш страниц.
.x разделяют
.x сообща используют
Более того, такая группа соединения может иметь несколько читающих соединений и одно пишущее (в состоянии EXCLUSIVE),
работающих в одно время с одной и той же БД. Уловкой есть то, что
эти соединения из разных нитей не могут разделять кэш, они строго ограничены одной нитью (именно работающей в
режиме разделяемого кэша), создавшей их. Более того, пишущие и читающие соединения должны быть готовы
обрабатывать специальные условия включающие блокировку таблиц.
.^
Когда читающие соединения читают таблицы, \nm автоматически создает блокировку таблиц для них.
Это предохраняет таблицы от изменения пишущим соединением. Если пишущее соединение пытается
изменить таблицу, заблокированную для чтения, то получает SQLITE\_LOCKED.
Та же логика применяется к читающим соединениям, пытающимся обратиться к таблицам заблокированным для записи.
Однако в этом случае, читающие соединнения могут идти далее и читать таблицы, которые были изменены пишущим соединением.
Правда оно должно работать в специальном режиме (read-uncommitted mode) чтения не фиксированных данных.
.x read-uncommitted mode
.x режиме чтения не зафиксированных данных
Его можно задавать при помощи прагмы $read\_uncommitted$
.x read\_uncommitted
.x прагма read\_uncommitted
В этом случае \nm не ставит на таблицы блокировку чтения. Как результат, читающие соединения вообще не замечают
пишущее. Однако, тогда они могут получить несогласованные данные, так ак пишущее соединение может изменить
таблицы во время чтения. Этот режим похож на уровень изолирования транзацкий с названием грязное чтение.
.x грязное чтение
.^
Этот режим разработан для встраиваемых серверов, которые нуждаются в экономии оперативной памяти и
в легком усилении конкуренции в определенных ситауциях.
Дополнительную информацию о том, как использовать этот режим с программным интерфейсом для C можно найти в гл.
.;+m1-6
.




.;2 +m1-5-7 Summary
.2 +m1-5-7 Итого
.^
Программный интерфейс \nm гибкий, интуитивно понятный и легкий
в использовании.
Он состоит из двух основных частей: базовый интерфейс
и дополнительный. Базовый интерфейс вращается возле двух основных
структур данных, которые используются для выполнения команд SQL:
соединений (connection) и операторов (statement).
Операторы выполняются за три шага: компиляция, выполнение
и финализация. Функции SQL $exec()$ и $get\_table()$ выполняют эти
три шага за один вызов функции, автоматически обрабатывая объекты, ассоциированные
с операторами. Дополнительный интерфейс предоставляет возможности
для дополнительной настройки \nm треми способами: при помощи функций, определяемых
пользователем; при помощи групповых функций, определяемых пользователем; при помощи сортирующих последовательностей,
определяемых пользователем.
.^
Так как модель конкуренции в \nm несколько отличается от других СУБД, то важно иметь некоторое
понимание как \nm управляется с транзакциями и блокировками, как они на деле выполняются и
как они работают внутри кода пользователя.
Вообще говоря, эти концепции не трудны для понимания и состоят из нескольких простых правил,
которые необходимо помнить, чтобы разрабатывать программы с использованием \nm .
.^
Все, уже рассказанное выше, будет уточняться в последующих главах,
так как эти концепции применимы не только к программному интерфейсу для языка C,
но к другим языкам, поскольку они построены на использовании интерфейса для C.

упс

Dima T
В этот момент очень вероятно возможно, что хотя менеджер страниц уже записал нужное нужные страницы в файл журнала, но операционная система ...


я это все стер и переписал по своему.
авторТак как менеджер страниц собираюет изменять БД, то лежащая на нем ответственность возрастает.
И работу эту надо сделать с максимальной тщательностью.
Перед началом вывода этих страниц в БД, он обращается к журналу.
От него требуется убедиться, что все содержимое журнала уже записано на диск (в его файле).
Вероятно, что
операционная система продолжает хранить многое, если не все в оперативной
памяти, несмотря на уже выполненные системные вызовы
От менеджера требуется еще раз (выполнив другие системные вызовы)
потребовать от неё завершить вывод этих страниц на поверхность диска в буквальном смысле.

автор.= Замечание
\nm пытается избежать клинча в конкретно этом сценарии, игнорируя вызов обработчика занятости (busy handler),
.x обработчик занятости
.x busy handler
.;++++
Обработчик занятости соединения в состоянии SHARED не вызывается, если предполагается, что
он будет мешать завершиться соединению в состоянии RESERVED.
.;++++ However, it is up to the code to get the hint.
Приложение может просто продолжать вызывать $step()$, и, в этом случае,
ничто не спасет \nm
.=
заменил на

автор.= Замечание
\nm пытается избежать клинча в конкретно этом сценарии, игнорируя вызов обработчика занятости (busy handler),
.x обработчик занятости
.x busy handler
.;++++
Обработчик занятости соединения в состоянии SHARED не вызывается, если предполагается, что
он будет мешать завершиться соединению в состоянии RESERVED.
Однако, понята ли подсказка зависит полсностью от приложения.
.;++++ However, it is up to the code to get the hint.
В случае, если оно будет просто продолжать вызывы $step()$
ничто не спасет \nm.
.=

ну, типа того

Dima TПо чистовику
c.112 что бы (слитно пишется) понять
Усталь, продолжение завтра :)
грепом нашел 27 вхождений неправильного что бы и заменил
)))

Dima T,
авторс.123 Атака при помощи SQL инъекции ИМХО слабовато выделено, в оригинале это вставки на сером фоне, а тут смотрится как очередной абзац

наконец, узнал как менять фон

большую часть пофискил.
авторExecuting Wrapped Queries wrapped (надо бы все по-русски)
с этим я пока подожду, чешутся руки
переписать эти объяснения.
После консультаций с White Owl, мне кажется
надо не операторы делить на подготавливаемые и немедленно выполняемые,
а функции из апи поделить на две группы :
группа, которая подготавливает операторы
и группа, которая немедленно выполняет операторы.

все больше глобальных изменений не будет