Java.util.Prefs throwing BackingStoreException - Почему?

У меня есть система, которая кэширует крошечные/простые результаты вызова SOAP при запуске

Мне нужны экземпляры, чтобы перезагрузить их кеш при запуске (в случае, если служба SOAP мертва) и ТАКЖЕ обрабатывают возможность использования нескольких экземпляров с использованием этого файла кэша

Я выбрал использовать java.util.prefs, но встроенный в автоматическую синхронизацию поток Java прерывается с ошибкой (1% времени с использованием синхронизации хранилища по умолчанию JVM 30s), сбрасывая следующее исключение:

Jan 8, 2010 12:30:07 PM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.

Я подозревал эту ошибку, но это было исправлено в 1.5 (tiger-b40), а наш java 5 в этом поле "1.5.0_16- b02".

Теперь я подозреваю, что это может быть потому, что у нас есть несколько JVM, которые используют этот Backing Store, хотя это, похоже, не происходит на наших других машинах.

Может ли кто-нибудь подтвердить это? Каковы риски, если таковые имеются?

Если мой подход ошибочен, что я должен использовать в качестве альтернативы?

Ответ 1

"Теперь я подозреваю, что это может быть потому, что у нас есть несколько JVM, которые используют этот резервный магазин"

Это может быть абсолютно так! Если две JVM пытаются заблокировать файл в то же самое, то это то, что вы увидите.

Точные данные будут зависеть от типа блокировки, операционной системы и файловой системы.

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

Ответ 2

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

Ответ 3

Я столкнулся с той же проблемой с причалом. Я нашел следующее исправление проблемы.

Добавьте .systemPrefs в каталог JRE и предоставите доступ к пользователю, который запускает процесс, который жалуется.

Как только это будет сделано, перейдите в каталог Jetty и откройте файл start.ini

- Djava.util.prefs.userRoot={user home directory}

- Djava.util.prefs.systemRoot={user home directory}

После завершения добавления этих строк я перезапустил причал и обнаружил, что ошибки не исчезли.