a lock marker file is created any time an IndexWriter is opened, and
(should be) cleaned up when the IndexWriter is closed.
So if you kill the application without properly closing the
IndexWriter, this problem is expected and you'll have to cleanup the
lock file manually.
With "exclusive_index_use=false", as it was by default in previous
version, the IndexWriter is opened for each operation, and closed
right after having applied all changes. So unless an index write was
being performed at the same time, when you suddenly terminate the
application the IndexWriter is likely already closed, so it would be
unlikely to need to cleanup locks, but it might still happen.
Of course using "exclusive_index_use=true" (the new default) is
significantly more efficient.
Note as well that you're dealing with SimpleFSLock, which is not
cleaned up on a process termination as the NativeFSLock would be, so
you could try "locking_strategy" configuration property set to
"native"; if you are really sure you could use "single" or
I would recommend against that especially in production as a wrongly
acquired lock will lead to index corruption.
Remember as well that the Hibernate SessionFactory should be closed to
cleanly release all index backend resources - including locks but also
background threads, so leftover locks should not be treated as a
problem but as an alarm meaning that something is wrong; if it happens
to you in CI as well, could you please investigate it? I suspect you
have some test which fails to cleanup properly, but if it's a leftover
from Search that would be a critical issue we need to fix, but I'm not
aware of current problems in this area.
On 30 December 2011 01:39, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
On Wed, Dec 28, 2011 at 2:21 PM, Guillaume Smet
> After our upgrade to 4.0 (from 3.4.1), we've started to have a lot of
> lock errors on our development boxes. I thought it was due to brutal
> kills of the JVM (typically Terminate in Eclipse) but we also have
> them in our CI environment on a project where every test is OK.
As the default configuration for 3.4 was to use the shared index mode,
I tried to use it in 4.0 by changing
hibernate.search.default.exclusive_index_use to false.
AFAICS, I don't have the lock problem anymore (so far).
So it seems the problem is with the exclusive index mode. As it's on
our personal development boxes, I suppose this mode should work
Note that on a team of 4 developers, we have the problem at least 4-5
times per developer per day.
hibernate-dev mailing list