¿Lucene.Net administra varios hilos que acceden al mismo índice, un índice mientras que el otro está buscando?

Question

Al usar Lucene.Net con ASP.NET, me imagino que una solicitud web puede desencadenar una actualización del índice mientras que otra solicitud web realiza una búsqueda. ¿Lucene.Net ha incorporado la posibilidad de gestionar el acceso simultáneo, o tengo que administrarlo, para evitar errores de "ser utilizado por otro proceso"?

EDITAR: Después de leer los documentos y la experimentación, esto es lo que creo que he aprendido: hay dos problemas, la seguridad del hilo y la concurrencia. El subprocesamiento múltiple es "seguro" en el sentido de que no se puede hacer nada malo con el índice. Pero, es seguro a costa de un solo objeto que tiene un bloqueo en el índice a la vez. El segundo objeto vendrá y lanzará una excepción. Por lo tanto, no puede dejar una búsqueda abierta y esperar que un escritor en otro hilo pueda actualizar el índice. Y si un hilo está ocupado actualizando el índice, entonces tratar de crear un buscador fallará.

Además, los buscadores ven el índice tal como estaba en el momento en que lo abren, por lo que si los mantienen actualizados y actualizan el índice, no verán las actualizaciones.

Quería que mis búsquedas vieran las últimas actualizaciones.

Mi diseño, y parece que está funcionando hasta el momento, es que mis escritores y buscadores comparten un candado, para que no fallen, solo esperan, hasta que se complete la escritura o búsqueda actual.

Answer 1

No tiene un problema con eso tanto como administrar escrituras concurrentes en el índice. He tenido un camino más fácil con SOLR, que abstrae la mayoría de esas diferencias, ya que se ejecuta como servidor.

Answer 2

Según this page,

indexación y búsqueda no sólo son hilo de seguridad, pero seguro proceso. Lo que esto significa es que:

• buscadores índice múltiples se pueden leer los archivos de índice Lucene al mismo tiempo.
• Un escritor índice o lector puede editar los archivos de índice Lucene, mientras que las búsquedas son curso
• escritores índices múltiples o lectores pueden tratar de editar los archivos de índice Lucene al mismo tiempo (es importante para el escritor índice/reader que se cerrará para que libere el bloqueo de archivos ). Sin embargo, el analizador de consultas no es seguro para subprocesos, por lo que cada subproceso que utiliza el índice debe tener su propio analizador de consultas .

El escritor índice sin embargo, es el hilo seguro, por lo que puede actualizar el índice mientras que las personas que están buscando. Sin embargo, debe asegurarse de que los hilos con índice abierto los busquen y abran los nuevos , para obtener los datos recién actualizados.

Answer 3

Es posible que tenga problemas, si su hilo de indexación es la creación de un nuevo documento que da lugar a la fusión de algunos segmentos del índice, a continuación, se eliminarán los segmentos fusionados y se crearán nuevo segmento.El problema es que el buscador de índice cargó todos los segmentos cuando se abrió, por lo que tiene "punteros" para los segmentos que existían cuando se abrió. Ahora, si el escritor del índice fusiona un segmento y elimina un segmento, su buscador de índice seguirá creyendo que ese archivo de segmento existe y fallará con un "error de archivo no encontrado". Lo que realmente necesita hacer es separar su índice de escritura de su índice de búsqueda, utilizando SOLR o haciendo su propia replicación de instantáneas de índice similar a lo que SOLR hace. Tengo un sistema muy similar a SOLR usando .NET y Lucene.NET en Windows, usando enlaces duros NTFS para hacer una replicación eficiente de instantáneas. Te puedo dar más información si estás interesado.