Недостатком этого метода могут быть возникновения тупиковых ожиданий. Если бы в нашем примере транзакция Т1, отработав с объектом р1, начала бы работу с объектом р2, то она тоже перешла в ожидание, поскольку объект р2 захвачен ранее транзакцией Т2. Выход из тупиковой ситуации – это построение графа ожидания транзакции. Каждая транзакция является вершиной этого графа. Если транзакция I ожидает, пока закончится j, то получается ребро.
В этом случае применяется принудительный откат какой-либо транзакции. Выбор той транзакции, откат которой обойдется «дешевле» всего, определяется на основе сложной оценки, в которую входят число накопленных захватов, приоритет пользователя, «вес» времени выполнения.
При описанном методе сериализации (метод двухфазного протокола) достигается полная сериализация транзакций. Однако, бывают случаи, когда важны скорость выполнения транзакции, а не ее точность. Например, надо иметь самое общее представление о картине торгов. При этом не важен факт каждой отдельной сделки. Для смягчения требований в этот метод вводится понятие уровня изолированности пользователя.
Всего выделяют 4 уровня:
1. Самый высокий – полностью соответствует описанному методу.
2. Уровень подтвержденного чтения. Транзакция не имеет доступа к промежуточным и окончательным результатам других транзакций, но транзакция может увидеть строку, добавленную в БД другой транзакцией (проблема строк-призраков).
3. Тоже связан с подтверждением чтения. Транзакция не имеет доступа к промежуточным результатам других транзакций, но ей доступны окончательные данные, полученные в ходе выполнения других транзакций.
На этом уровне если транзакция пытается обновить строку, уже обновленную другой транзакцией, то она будет удалена во избежание проблемы пропавшей строки.
4. Уровень неподтвержденного (или «грязного») чтения. Текущей транзакции видны промежуточные и несогласованные данные и ей тоже доступны строки-призраки, но СУБД предотвращает пропавшие обновления.
Одним из основных требований к развитым БД является надежность хранения БД. Это требование предполагает возможность восстановления согласованного состояния БД после любого аппаратного или программного сбоя.
Следующие ситуации, при которых требуется восстановить состояние БД:
1. Индивидуальный откат транзакций. Например, ее завершение оператором ROLLBACK.
2. Восстановление после «мягкого» сбоя, т.е. после внезапной потери содержимого ОЗУ. Например, отключение напряжения в сети или неустранимый сбой в работе процессора.
3. Восстановление после «жесткого» сбоя, т.е. после поломки основного внешнего носителя.