java.util.Prefs throwing BackingStoreException - Why?

I have a system that caches the tiny/simple results of an on-startup SOAP call

I need instances to be able to reload their cache on startup (in case the SOAP service is dead) and ALSO handle the possibility of multiple instances using this cache file

I chose to开发者_JAVA技巧 use java.util.prefs but Java's builtin automatic sync thread is intermittently failing (1% of time using default JVM 30s backing store sync) dumping the following the exception:

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.

I suspected this bug but this was fixed in 1.5(tiger-b40) and our java 5 on this box is "1.5.0_16-b02".

I now suspect that it might be because we have multiple JVMs sharing this Backing Store, although this doesn't seem to happen on our other machines.

Can anyone confirm this? What are the risks, if any?

If my approach is flawed what should I be using as an alternative?

"I now suspect that it might be because we have multiple JVMs sharing this Backing Store"

This could absolutely be the case! If two JVMs attempt to lock the file at the same then this is what you'll see.

The exact details will depend on the type of lock, operating system and file system.

You might want to try wrapping the operation that causes this in a try/catch block, then retry the operation if it fails.

I ran into the same issue with jetty. I found the following fixed the issue.

Add a .systemPrefs to your JRE directory and provide access to the user who is running the process which is complaining.

Once that is done, go to the Jetty directory and open the start.ini file

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

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

Once finished adding those lines I restarted jetty and found that the errors were gone.

Instead of using Preferences, just use any serializable Map and make a very simple cache class which serializes and deserializes it to a randomly-generated temporary filename (the filename being generated on first initialisation). Since it is only a cache, you can just catch any exceptions and reset the cache back to its initial state when an exception happens, so it will re-fetch from the original data source (the SOAP service in your case). So there's no need to worry about serialVersionUID or any of that compatibility stuff, if you don't want to.