Основные понятия JCR

Недавно я работал с Magnolia CMS, которая использует JCR.

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

Я понимаю JCR следующим образом:

  1. JCR — это спецификация, существует несколько реализаций
  2. Jackrabbit — это одна из реализаций JCR.
  3. Jackrabbit может хранить информацию, используя файловую систему напрямую или используя базу данных, такую ​​​​как MySQL.

Теперь мои вопросы

  1. Как создать резервную копию и восстановить репозиторий JCR?
  2. Есть ли какой-то конкретный инструмент, который можно использовать для проверки целостности данного JCR и попытки его исправления? Я немного поиграл с Торомиро.
  3. Есть ли какой-либо конкретный информационный/учебный ресурс, который мне следует прочитать, чтобы получить полное и правильное представление о технологии JCR?

Обновлять:

У меня есть другие вопросы:

  1. Если конкретная реализация JCR хранит контент в базе данных, могу ли я ожидать, что ВЕСЬ контент будет храниться в этой базе данных, или может случиться так, что некоторый контент (например, изображения) будет храниться непосредственно в файле системе, а не в базе данных?
  2. В настоящее время у нас есть репозиторий JCR, к которому обращаются три разных веб-сервера, насколько я понимаю, спецификация JCR учитывает эту ситуацию и защищает репозиторий, чтобы предотвратить несогласованность содержимого из-за одновременного доступа для записи. Это правильно?
  3. Чтобы быть конкретным, проблема, с которой мы столкнулись, состояла в том, что узел A содержал ссылку на узел B, но узел B был недоступен, после использования groovy-скрипта нам удалось удалить узел B (который, казалось, находился в несогласованное состояние), однако, как мы могли найти все ссылки на узел B (возможно, на него ссылался не только узел A, но и узел C). Что, черт возьми, могло привести к повреждению репозитория JCR? Кстати, мы также пытались использовать флаги forceConsistencyCheck, autorepair и enableConsistencyCheck, но это не решило проблему.

Спасибо


person Juan Antonio Gomez Moriano    schedule 18.02.2014    source источник


Ответы (1)


Вы правильно понимаете JCR: это спецификация, реализованная несколькими проектами (включая Jackrabbit, ModeShape, Alfresco, eXo и т. д.). На самом деле существует несколько версий JCR (1.0, 2.0 и очень скоро 2.1), и не все реализации поддерживают все версии JCR.

(Полное раскрытие: я основатель и руководитель ModeShape.)

Не существует стандартного или универсального способа резервного копирования репозитория JCR, но некоторые из реализаций предлагают свои собственные механизмы. Например, если все хранится в СУБД, то можно использовать функцию резервного копирования и восстановления СУБД. У Jackrabbit есть собственный механизм резервного копирования, как и ModeShape.

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

Я не знаю каких-либо замечательных книг или онлайн-ресурсов JCR, но взгляните на Документация по Jackrabbit и Документация по ModeShape .

person Randall Hauch    schedule 18.02.2014
comment
Спасибо за внимание, есть ли способ заставить весь контент жить в СУБД? Я не делал проверку целостности с помощью toromiro, я просто использовал его немного в надежде, что я помогу. Пожалуйста, посмотрите мой обновленный вопрос и помогите мне своими знаниями, очень признателен. - person Juan Antonio Gomez Moriano; 19.02.2014
comment
Что и где хранится, вероятно, зависит от конфигурации конкретной реализации JCR. (ModeShape может хранить весь контент в реляционной базе данных, хотя мы рекомендуем не использовать индексы, поскольку запросы становятся слишком медленными.) Люди, более знакомые с Jackrabbit, должны будут ответить на ваши вопросы по проверке согласованности. - person Randall Hauch; 19.02.2014