java.util.Prefs throwing BackingStoreException - ¿Por qué?

Question

Tengo un sistema que almacena en caché los resultados diminutos/simples de una llamada SOAP on-startup

Necesito casos para poder recargar su caché en el arranque (en caso de que el servicio SOAP está muerto) y también se encargan de la posibilidad de varias instancias utilizando este archivo de caché

he elegido utilizar java.util.prefs pero incorporado hilo sincronización automática de Java es intermitente fallando (1% del tiempo usando 30s JVM predeterminada que respaldan tienda de sincronización) el vertido de la siguiente excepción:

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. 

sospechaba this bug pero esto fue arreglado en 1.5 (tiger-b40) y nuestro java 5 en esta caja es "1.5.0_16-b02".

Ahora sospecho que puede deberse a que tenemos varias JVM que comparten esta Tienda de respaldo, aunque esto no parece suceder en nuestras otras máquinas.

¿Alguien puede confirmar esto? ¿Cuáles son los riesgos, si los hay?

Si mi enfoque es defectuoso, ¿qué debería estar usando como alternativa?

Answer 1

"Ahora sospechan que podría ser porque tenemos varias JVM que comparten esta Almacenamiento de respaldo"

Este podría ser el caso en absoluto! Si dos JVM intentan bloquear el archivo al mismo tiempo, esto es lo que verá.

Los detalles exactos dependerán del tipo de cerradura, sistema operativo y sistema de archivos.

Puede desear intentar ajustar la operación que causa esto en un bloque try/catch, luego reintentar la operación si falla.

Answer 2

En lugar de usar Preferencias, simplemente use cualquier Mapa serializable y cree una clase de caché muy simple que lo serialice y deserialice en un nombre de archivo temporal generado aleatoriamente (el nombre del archivo se genera en la primera inicialización). Como solo es un caché, puede capturar cualquier excepción y restablecer el caché a su estado inicial cuando ocurre una excepción, por lo que volverá a buscar desde el origen de datos original (el servicio SOAP en su caso). Así que no hay necesidad de preocuparse por serialVersionUID o cualquiera de esas cosas de compatibilidad, si no lo desea.

Answer 3

Me encontré con el mismo problema con embarcadero. Descubrí que lo siguiente solucionó el problema.

Agregue .systemPrefs a su directorio JRE y proporcione acceso al usuario que está ejecutando el proceso que se queja.

Una vez hecho esto, vaya al directorio del embarcadero y abra el archivo start.ini

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

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

Una vez terminado de añadir esas líneas me reinicia embarcadero y encontraron que los errores se habían ido .