java.util.Prefs 抛出 BackingStoreException - 为什么？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2027566/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
java.util.Prefs throwing BackingStoreException - Why?
提问by HaveAGuess
I have a system that caches the tiny/simple results of an on-startup SOAP call
我有一个系统可以缓存启动时 SOAP 调用的微小/简单结果
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
我需要实例能够在启动时重新加载它们的缓存（以防 SOAP 服务已死）并且还处理使用此缓存文件的多个实例的可能性
I chose to use java.util.prefsbut Java's builtin automatic sync thread is intermittently failing (1% of time using default JVM 30s backing store sync) dumping the following the exception:
我选择使用，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.
I suspected this bugbut this was fixed in 1.5(tiger-b40) and our java 5 on this box is "1.5.0_16-b02".
我怀疑这个错误，但这在 1.5(tiger-b40) 中得到了修复，我们在这个盒子上的 java 5 是“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.
我现在怀疑这可能是因为我们有多个 JVM 共享这个后备存储，尽管这在我们的其他机器上似乎没有发生。
Can anyone confirm this? What are the risks, if any?
任何人都可以证实这一点吗？如果有，有什么风险？
If my approach is flawed what should I be using as an alternative?
如果我的方法有缺陷，我应该使用什么作为替代方案？
回答by Kevin Wright
"I now suspect that it might be because we have multiple JVMs sharing this Backing Store"
“我现在怀疑这可能是因为我们有多个 JVM 共享这个后备存储”
This could absolutely be the case! If two JVMs attempt to lock the file at the same then this is what you'll see.
绝对有可能是这样！如果两个 JVM 尝试同时锁定文件，那么这就是您将看到的。
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.
您可能想尝试将导致此问题的操作包装在 try/catch 块中，然后在失败时重试该操作。
回答by Robin Green
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.
而不是使用首选项，只需使用任何可序列化的 Map 并制作一个非常简单的缓存类，将其序列化和反序列化为随机生成的临时文件名（在第一次初始化时生成的文件名）。由于它只是一个缓存，因此您可以捕获任何异常并将缓存重置为异常发生时的初始状态，因此它将从原始数据源（在您的情况下为 SOAP 服务）重新获取。因此，如果您不想，则无需担心 serialVersionUID 或任何此类兼容性问题。
回答by user2981810
I ran into the same issue with jetty. I found the following fixed the issue.
我在码头遇到了同样的问题。我发现以下解决了这个问题。
Add a .systemPrefsto your JRE directory and provide access to the user who is running the process which is complaining.
将 a 添加.systemPrefs到您的 JRE 目录，并为正在运行抱怨的进程的用户提供访问权限。
Once that is done, go to the Jetty directory and open the start.inifile
完成后，转到 Jetty 目录并打开start.ini文件
-Djava.util.prefs.userRoot={user's home directory}
——Djava.util.prefs.userRoot={user's home directory}
-Djava.util.prefs.systemRoot={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.
添加完这些行后，我重新启动了码头，发现错误消失了。
