Примеры кода, в которых используются мелкозернистые замки (JCR Jackrabbit?)

Question

Я занимаюсь научными исследованиями, пытаясь разработать инструмент программирования, который помогает реализовать мелкозернистые функции блокировки для параллельных программ, которые поддерживают древовидные структуры данных.

Например, программист может написать некоторые функции, которые получают корневой узел дерева и модифицируют дерево (путем перемещения по некоторым маршрутам и добавления/удаления узлов), а инструмент поможет ему найти, где в кодовых узлах должны быть заблокированы и где они могут быть освобождены - поэтому функции могут выполняться одновременно на одном и том же дереве.

Я ищу примеры реальных примеров кода, в которых используется такая мелкозернистая блокировка, или где она может быть использована для повышения производительности, но программист был слишком ленив для ее реализации (например, он заблокировал все дерево во время вызова функции без освобождения бесполезных узлов).

Я читал о JCR & Jackrabbit, которые используют базу данных древовидные, и нашел статью, в которой описывается, как блокировать узлы в JCR (но без примеров): http://www.day.com/specs/jcr/2.0/17_Locking.html

У меня есть очень небольшой опыт работы в базы данных, и я не совсем понимаю, что разрешено, и что не допускается, когда речь заходит о базах данных и параллелизма в Jackrabbit. Доступ к одному узлу из 2 потоков не разрешен, но как насчет разных репозиториев? И что произойдет, если два разных клиента попытаются получить доступ к одному и тому же узлу (например, один пытается удалить его, а другой пытается его изменить) будет ли session.save() сбой?).

Спасибо, Орен

Answer 1

Прежде всего, не запутаться между базами данных// блокировки зайца. Jackrabbit реализует свою собственную блокировку, также как и базы данных.

Jackrabbit позволяет блокировать узлы, используя LockManager.lock(). Установка параметра isDeep в значение true означает, что все узлы внизу также будут заблокированы. Заблокированный узел может быть прочитан другим сеансом, но его нельзя изменить.

Технически говоря, 2 нити МОЖНО отредактировать один и тот же узел, если они используют один и тот же сеанс, но это довольно опасно и, вероятно, его следует избегать.

Если узел, вероятно, будет изменен на 2 одновременных сеанса, вы должны всегда блокировать узел. Которая когда-либо сессия добирается до последнего, должна ждать выхода блокировки. Если вы не заблокируете, по крайней мере один из сеансов вызовет исключение.

Я не уверен, что вы имеете в виду, обратившись к узлам из разных хранилищ. Узел может принадлежать только одному репозиторию. Если вы имеете в виду, что 2 экземпляра-получателя получают доступ к одной и той же базе данных, этого также следует избегать или вы должны использовать кластеризацию.

При реализации блокировки он будет зависеть от вашего дизайна и требований. Там нет точки блокировки, если у вас будет только один сеанс и наоборот. Блокировка узла или поддерева будет зависеть от того, что представляют ваши данные. Например, если узел представляет папку, вы, вероятно, захотите заблокировать только узел, а не весь поддерево. Если поддерево представляет собой сложный документ, вы, вероятно, захотите заблокировать поддеревье.

Что касается блокировки всего дерева, я надеюсь, что я не знаком с тем, кто это делает!