如何处理Hibernate-Search索引恢复? [英] How to handle Hibernate-Search index recovery?

问题描述

当应用程序服务器意外退出时，Hibernate Search无法正常关闭Lucene.在每个索引目录中保留 write.lock 文件.那当然是很正常的.但是-重新启动应用程序后，锁定文件也仍然保留.有时会导致锁定超时异常.

When an application server exits unexpectedly, Hibernate Search can not do a graceful shutdown of Lucene. Leaving write.lock files behind in each index directory. That is of course quite normal. But - the lock files also remain after restarting the application. Which causes lock timeout exceptions at some time.

我的问题是是否有通常的方式来处理恢复.

My question is whether there is a usual way to handle the recovery.

首先想到的是检查是否存在write.lock文件.如果找到一个索引，则将其删除并重建所有索引.但是也许Hibernate-Search在正确配置后会自动执行此操作吗?

What comes first at mind would be to check for the presence of write.lock files. If one is found, they are removed and all indices are rebuilt. But maybe Hibernate-Search does this automatically when properly configured ?

推荐答案

如果Hibernate Search要在引导时删除锁定文件，则可能由于错误地将两个应用程序配置为在同一索引上运行而可能破坏索引.因此，不删除锁定文件是锁定的目的.

if Hibernate Search were to remove lock files at boot, it might risk to destroy your index if by mistake you configured two applications to run on the same index. Hence not deleting the lock file is the purpose of the lock.

还是，我们意识到这很烦人:如果可以使用Native LockFactory ( http://docs .jboss.org/hibernate/search/4.1/reference/zh-CN/html_single/#search-configuration-directory-lockfactories ) 甚至崩溃/终止的JVM也会释放锁定文件.

Still, we realized this was annoying: if you can use the Native LockFactory ( http://docs.jboss.org/hibernate/search/4.1/reference/en-US/html_single/#search-configuration-directory-lockfactories ) even a crashed / killed JVM will release the lock files.

如果您升级到最新版本，则在检测到的平台足够安全的情况下，默认情况下将使用本机.

If you upgrade to latest versions, Native is used by default if the detected platform is considered safe enough.

这篇关于如何处理Hibernate-Search索引恢复?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！