lucene-java-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Lucene-java Wiki] Update of "AvailableLockFactories" by SanneGrinovero
Date Sun, 29 Nov 2009 20:10:46 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Lucene-java Wiki" for change notification.

The "AvailableLockFactories" page has been changed by SanneGrinovero.
http://wiki.apache.org/lucene-java/AvailableLockFactories?action=diff&rev1=1&rev2=2

--------------------------------------------------

  
  While both F``S``Directory and R``A``M``Directory have sensible defaults you might want
to consider an alternative for finetuning of performance, or because you are storing the index
on some multiple-node shared resource having issues with file based locking.
  
- /!\ :TODO: /!\
+ /!\ Using an inappropriate Lock``Factory will have your index corrupted! Make sure you understood
the Lock design.
  
+ <<TableOfContents(2)>>
+ 
+ = Core LockFactory implementations =
+ 
+ == NativeFSLockFactory ==
+ 
+ Qualified Class``Name: {{{org.apache.lucene.store.NativeFSLockFactory}}}
+ 
+ This implementation is similar to Simple``F``S``Lock``Factory, they both extend F``S``Lock``Factory
and rely on a lock file. This version relies on N``I``O and the lock files will be properly
removed (by the OS) if the JVM has an abnormal exit, but should be avoided on N``F``S: make
sure you read the javadocs for updated details.
+ 
+ ----
+ 
+ == NoLockFactory ==
+ 
+ Qualified Class``Name: {{{org.apache.lucene.store.NoLockFactory}}}
+ 
+ As the name reminds, this Lock``Factory will not do anything. This is useful when you're
sure that only one thread at a time will ever attempt to apply changes to the index. Using
it could be reasonable when your application is designed in such a way, and you can also guarantee
that no other processes will attempt to apply changes. If you're not sure to meet these rare
requirements, avoid it.
+ 
+ ----
+ 
+ == SimpleFSLockFactory ==
+ 
+ Qualified Class``Name: {{{org.apache.lucene.store.SimpleFSLockFactory}}}
+ 
+ This implementation is similar to Native``F``S``Lock``Factory, they both extend F``S``Lock``Factory
and rely on a lock file. This is the default implementation of F``S``Directory: it will write
a lockfile to filesystem when the lock is acquired and delete the file when it's released,
making it a safe choice for almost all configurations. The drawback of this implementations
is that it might happen when the J``V``M holding the lock crashes that you have to manually
remove the stale lock file.
+ 
+ ----
+ 
+ == SingleInstanceLockFactory ==
+ 
+ Qualified Class``Name: {{{org.apache.lucene.store.SingleInstanceLockFactory}}}
+ 
+ Uses an object instance to represent the lock, so this is usefull when you are certain that
all modifications to the a given index are running against a single shared in-process Directory
instance. This is currently the default locking for R``A``M``Directory, but it could also
make sense on a F``S``Directory provided the other processes use the index in read-only.
+ 
+ ----
+ 
+ == VerifyingLockFactory ==
+ 
+ Qualified Class``Name: {{{org.apache.lucene.store.VerifyingLockFactory}}}
+ 
+ This Lock``Factory was designed to test other implementations, it's recommended to read
it's javadocs and make use of it when you want to implement your own Lock``Factory.
+ 
+ ----
+ 
+ = Additional implementations of interest =
+ 
+ == Infinispan LockFactory ==
+ 
+ Infinispan is an open source data grid platform written in Java: http://www.jboss.org/infinispan
+ 
+ It includes a distributed Directory implementation for Lucene and a Lock``Factory. While
this implementation was designed initially to be used with Infinispan Directory it might also
be useful combined to other Directory implementations. The Lock uses Infinispan and J``Groups
behind the scenes to provide auto-discovery at network level, making it simple for both network
shared Directories or local Directories shared by applications in multiple V``Ms to have a
reliable lock independent from the file-system; another advantage especially when combined
with it's sister Directory is that nodes will find each-other without having to maintain configuration
files as the nodes are dynamic.
+ 
+ For more information refer to Infinispan's documentation and this wiki: http://www.jboss.org/community/wiki/InfinispanasaDirectoryforLucene
+ 
+ ----
+ 
+ /!\ :TODO: add other implementations /!\
+ 

Mime
View raw message