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
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.
"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.