2.11.3 Index locking
To enforce a single writer at a time, which means an IndexWriter or an IndexReader doing deletions or changing norms, Lucene uses a file-based lock: if the lock file (write.lock by default) exists in your index directory, a writer currently has the index open. Any attempt to create another writer on the same index will hit a LockObtain- FailedException. This is a vital protection mechanism, because if two writers are acci- dentally created on a single index, that would quickly lead to index corruption.
Lucene allows you to change your locking implementation: any subclass of Lock- Factory can be set as your locking implementation by calling Directory.setLock- Factory. Be sure to call this before opening an IndexWriter on that Directory instance. Normally you don’t need to worry about which locking implementation you’re using. It’s usually only those advanced applications that have multiple comput- ers or JVMs that take turns performing indexing that may need to customize the locking implementation. Table 2.4 lists the core locking implementations provided with Lucene.
Table 2.4 Locking implementations provided by Lucene
To enforce a single writer at a time, which means an IndexWriter or an IndexReader doing deletions or changing norms, Lucene uses a file-based lock: if the lock file (write.lock by default) exists in your index directory, a writer currently has the index open. Any attempt to create another writer on the same index will hit a LockObtain- FailedException. This is a vital protection mechanism, because if two writers are acci- dentally created on a single index, that would quickly lead to index corruption.
Lucene allows you to change your locking implementation: any subclass of Lock- Factory can be set as your locking implementation by calling Directory.setLock- Factory. Be sure to call this before opening an IndexWriter on that Directory instance. Normally you don’t need to worry about which locking implementation you’re using. It’s usually only those advanced applications that have multiple comput- ers or JVMs that take turns performing indexing that may need to customize the locking implementation. Table 2.4 lists the core locking implementations provided with Lucene.
Table 2.4 Locking implementations provided by Lucene
Locking class name
|
Description
|
NativeFSLockFactory
This is the default locking for FSDirectory, using java.nio native OS locking, which will never leave leftover lock files when the JVM exits. But this locking implementation may not work cor- rectly over certain shared file systems, notably NFS.
SimpleFSLockFactory
Uses Java’s File.createNewFile API, which may be more portable across different file systems than NativeFSLockFactory. Be aware that if the JVM crashes or IndexWriter isn’t closed before the JVM exits, this may leave a leftover write.lock file, which you must manually remove.
SingleInstanceLockFactory
Creates a lock entirely in memory. This is the default locking implementation for RAMDirectory. Use this when you know all IndexWriters will be instantiated in a single JVM.
NoLockFactory
Disables locking entirely. Be careful! Only use this when you are absolutely certain that Lucene’s normal locking safeguard isn’t necessary—for example, when using a private RAMDirectory with a single IndexWriter instance.
from lucene in action
from lucene in action
댓글 없음:
댓글 쓰기