Здесь описывается, как рассчитать количество объектов блокировки, необходимых вашему приложению, хотя обычно достаточно конфигурации по умолчанию для объекта блокировки (1000). Он описывает, сколько объектов блокировки потребуется для данной отдельной операции доступа к данным, чтобы вы могли умножить это число на число одновременных операций доступа к данным и соответствующим образом настроить количество объектов блокировки. Это на самом деле не говорит о конфликте блокировок.
Для метода доступа HASH данное значение ключа отображается непосредственно в хэш-корзину. Существует только одна страница, на которую нужно посмотреть (и заблокировать), чтобы получить доступ к данным. Это отличается от Btree (который должен проходить по внутренним индексным узлам, чтобы получить доступ к данным) и Queue (который должен блокировать каждую запись и страницу, на которой находится запись).
В последних выпусках мы фактически устранили некоторые блокировки, которые не требовались, так что более простой способ выразить это было бы:
Для каждой операции с базой данных требуется
- Один объект блокировки для страницы (Btree, Hash или Recno) или записи (Очередь), к которой осуществляется доступ,
- plus Один объект блокировки для страницы метаданных,
- плюс Один объект блокировки , если требуется разделение страницы Btree,
- плюс Один объект блокировки на страницу , если Очередь используется
Обычно 2-3 блокировки объектов на доступ к данным. Транзакции накапливают объекты блокировки до тех пор, пока транзакция не будет завершена, поэтому, если транзакция в вашем приложении обычно обращается к 10 записям, эта транзакция потребует 20-30 объектов блокировки. Если в вашем приложении может быть до 10 одновременных потоков, вам необходимо настроить систему на наличие около 300 объектов блокировки. Всегда лучше сконфигурировать больше, чем вам нужно, чтобы вы не исчерпали себя, а нагрузка на память при чрезмерном распределении объектов блокировки минимальна (это небольшие структуры).
Надеюсь, это поможет.
Dave