lucenenet-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Haberl Norbert <>
Subject AW: What is best practice architecture in ASP.NET (Web) application(s) ?
Date Mon, 18 Sep 2017 06:11:02 GMT
So in case of ASP.NET I will implement a service layer as singleton and call it when needed.
Within that layer I can reopen the reader as new docs where indexed over the writer.

Any thoughts on this?

Best regards,
Norbert Haberl | Software Engineer | Customer Service & Support
Phone +43 316 6096 - 8435
SSI SCHÄFER | SSI Schäfer Automation GmbH | Fischeraustraße 27 | 8051 Graz | Austria
Website | Blog | YouTube | Facebook

-----Ursprüngliche Nachricht-----
Von: Paul Irwin [] 
Gesendet: Freitag, 15. September 2017 16:19
Betreff: RE: What is best practice architecture in ASP.NET (Web) application(s)

For 3.0.3, generally you should share (i.e. make static) an IndexReader where possible, potentially
checking IsCurrent to see if it needs to be reopened. From the official docs: 

"NOTE: IndexReader instances are completely thread safe, meaning multiple threads can call
any of its methods, concurrently. If your application requires external synchronization, you
should not synchronize on the IndexReader instance; use your own (non-Lucene) objects instead."

As for writes, I recommend if possible having a single writer (single process, single server)
to avoid dealing with LockObtainFailedExceptions from concurrency. Do not keep an IndexWriter
open longer than needed, and ensure you have proper error handling to make sure the lock is
disposed of. Otherwise your index will get locked and may or may not be in an invalid state
needing repair. If you are expecting a constant flood of writes (many per second sustained)
and cannot batch them then you can keep it open but you do run a greater risk of the process
being unexpectedly terminated and your index being locked or worse. If you are in that boat,
commit often. If you absolutely need multiple writers (I strongly question this), expect a
LockObtainFailedException and use something like the Transient Fault Handling Application
Block and/or a queue to retry. But again, best case scenario is infrequent or batched writes
with a single writer that is opened, committed, and disposed of as soon as possible.

Since the question is about best practices for architecture when using Lucene, unless it is
a trivially simple app, I would recommend having some kind of service/API layer to do all
of your Lucene work, and call that from the web application.


-----Original Message-----
From: JA Purcell []
Sent: Friday, September 15, 2017 9:32 AM
Subject: Re: What is best practice architecture in ASP.NET (Web) application(s)

I also have the same question, but I am currently using Lucene 3.03 along with an ASP.NET
application.  Since the web app isn't the only writer to the index, I created a service that
receives messages via SQL Service Broker that are to be indexed.  The service only uses one
instance of the writer at a time shared among many threads.

I am currently using a new instance of an IndexReader per request as an initial implementation,
but I know the best practice is to use only one instance of a reader as much as possible because
of initialization costs.

I'm currently experimenting with building a large index as quickly as possible, and so far
it seems that by using multiple processes writing to sub-indexes and combining them in the
end is the fastest way to get it done.


On Fri, Sep 15, 2017 at 3:29 AM Haberl Norbert <> wrote:

> Hey,
> what is generally the best practice architecture when using Lucene 
> within an ASP.NET web application (let's say MVC).
> Should ONE instance of IndexReader be declared or per request? Same 
> for writers ... shall all writes be queued?
> I guess it's a common scenario to use Lucene within a web app for 1st 
> level tier or as a separate search index but it's not clear how to use 
> it definetly.
> Would be great to hear what you think (I'm gonna make a blog post out 
> of this on my site)
> Best regards,
> Norbert
View raw message