Вот здесь можно узнать больше об базе данных cloudscape - часть 4

Материал из DOM

[править] Cloudscape. Часть 4

Более детальное рассмотрение транзакций требует общего представления о задачах синхронизации и способах их решения. Существуют следующие классические задачи синхронизации.

1.   Задача взаимного исключения, в данном случае существует некоторый 
неразделяемый ресурс и некоторое количество потребителей заинтересованных в нем. 
Как только один процесс захватил ресурс остальные должны ждать пока первый не освободит его.
2.   Задача “Производители-потребители”. В наиболее простой формулировке существует 
только один потребитель и только один производитель некоторого ресурса, 
которые выполняются одновременно. Взаимодействие же между ними идет через 
специальный буфер, вспомогательную переменную емкостью одна единица продукции. 
В общем случае следует согласовать скорость работы обоих участников. 
В ситуации когда производитель работает быстрее потребителя возможно ситуация 
что за время в течении которого потребитель потребил одну единицу продукции 
производитель успел произвести несколько единиц, которые помещал в буфер емкостью 
одна единица, а следовательно затирал старые значения, которые никогда не 
были получены и обработаны потребителем, (представьте себе банковскую систему 
в которой были потеряны переводы денег из-за такой разницы в скорости работы). 
Проблемы возникающие в случае если потребитель работает быстрее производителя, 
также неприятны. Будут обработаны несколько раз одни и те же данные. 
В более сложной формулировке данная задача предполагает наличия нескольких 
производителей и потребителей и возможность варьировать размер буфера обмена.
3.	Задача “Читатели-писатели”. В данной задаче предполагается наличие 
нескольких потоков, которые можно условно разделить на читающие информацию из 
некоторой общей переменной и записывающей туда информацию. Очевидно что данная 
задача требует взаимоисключения потоков, но более деликатную чем в задаче первой. 
Ведь если несколько читателей пытаются одновременно взять значение из промежуточной 
переменной то несогласованности не возникает. Но как только к буферу обращается 
писатель, то он должен исключать не только читателей, но и писателей.
4.	Задача “Обедающие философы”. Вкратце ее суть можно представить так: 
есть 3 мудрых китайских философа, которые собрались перекусить. 
Перед ними находится общее блюдо с лапшой и три палочки. Для того чтобы начать 
есть философ должен взять в руки две палочки. Если ему удалось ухватить только 
одну палочку, то он будет ожидать вторую которую должен будет освободить другой философ, 
как только закончит прием пищи. Однако представим себе ситуацию, когда все три философа 
одновременно взяли в руки по одной палочке и теперь терпеливо ждут, когда же освободится 
следующая палочка. А раз сосед никогда не отдаст палочку раз он сам ждет когда же ему 
отдадут вторую необходимую для еды палочку, следовательно первому, второму, и разумеется 
третьему философу  придется ждать вечно и умереть от голода. Разумеется, что это одни 
из немногих, но достаточно интересные задачи, которые приходится постоянно решать 
разработчикам операционных систем, СУБД, и других приложений работающих 
в многопользовательском режиме.

Возвращаясь к cloudscape можно сказать, что существует три вида блокировки ресурсов. Первый способ это монопольное использование. Суть очень проста – один и только один клиент может работать с БД. Разумеется, что несмотря на свою простоту и легкость в реализации, данный подход не имеет практического применения при построении распределенных и многопользовательских систем. Второй вид блокировки – так называемая общая блокировка, она похожа на действия в случае второй классической задачи синхронизации “читатели-писатели”, когда читатели могли одновременно обращаться к набору данных. Следует понимать, что даже когда вы делаете обычный запрос на выборку данных, то неявно уже начинается новая транзакция, завершаемая как только вы доходите до последней записи. Существует также и третий вид блокировки – это “update lock”. Данная блокировка возникает в случае когда создается курсор для обновления. Эта блокировка может перейти в эксклюзивную блокировку когда выполняется инструкция изменения данных dml.

При работе с транзакциями и синхронизацией обязательно следует помнить о deadlock. Пример возможной ситуации deadlock был приведен в примере с обедающими философами когда захват ресурса и нежелание поделиться с другими приводило к гибели всех философов. Как избежать подобных ситуаций? Часть проблем может отсечь сам разработчик за счет логики работы программы, когда приложению необходимы одновременно две или более таблицы то можно сделать попытку их захвата, а если не удалось захватить какую-то из них, то обязательно следует освободить те которые удалось захватить и не жадничать. Разумеется данный подход не рационален за счет напрасной траты ресурсов времени. В общем случае возможны два подхода как избежать deadlock-ов либо мы не допускаем их, либо своевременно обнаруживаем и принимаем меры по исправлению. К первому способу можно отнести использование конструкции “lock table”. Во втором же способе достаточно эффективный контроль ведет сама cloudscape, когда устанавливает timeout времени выполнения захвата ресурса. На время ожидания можно влиять изменяя системное свойство “db2j.locks.waitTimeout”, значение данного свойства по умолчанию 180 секунд. Если же установить значение “–1”, то ожидание будет вечным, лимит времени будет снят. В качестве своеобразной иллюстрации механизма блокировки можно будет разработать приложение, которое создает n-ое количество клиентов обращающихся к таблицам БД, причем сам характер их обращения предполагает наличие блокировок. И отображающий кривую зависимости количества конфликтов от количества одновременных запросов. Для проверки того что запрошенная операция была отменена вследствие возникшего deadlock можно воспользоваться следующим фрагментом кода.

try{
// Некоторые действия
}
catch (SQLExce
tion e){
 if (e.getSQLState.equals(“40001”)) значит возникла блокировка
}