The indexreader take a snapshot of the current index in the directory. If you modify it, you mus't tell the reader to reopen it. Right now nhibernate search do it when when you write something to the index, so you must implement a way to tell the index to reopen. You can throw the workspace and create a new one for example.
I just created an jira issue tu upgrade to lucene.net 2.3.2 It have several performance benefits on indexing, also adds a reopen method to the index reader so it can read the changes without having to drop an read again all the cache. I expect to be disponible soon, as all the work is done and need a bit of test and pass all the apache release process. (But i'm currently using it without any problem and with a big performance benefits in indexing speeds as you can read in the another thread). On Tue, Nov 25, 2008 at 11:46 AM, Vito Vessia <[EMAIL PROTECTED]> wrote: > > Thank you very much for your answer. I've only a last question: can I > leave the nh.search on the SAN so all the back-end servers can always > read an updated index instead of a local copy of this index constantly > updated? In this way I have not to provide an indexreaders refresh > because the index is always consistent. The scheduled indexer takes > care about the mass update of the indexes and all the backed just read > the index with no lock or update on it. Is that a correct way? > > --Vito > > > > On 25 Nov, 11:16, "Jokin Cuadrado" <[EMAIL PROTECTED]> wrote: >> On Tue, Nov 25, 2008 at 10:36 AM, Vito <[EMAIL PROTECTED]> wrote: >> > All the backend servers are equivalent so there is no special master >> > and all the business services running on these backend servers may >> > update NH.Search/Lucene indexes. The indexes update is contextual. >> > If I configure my back end servers in master/slaves mode, is there an >> > automatic way/setting to queue all updates on a master server from all >> > the slave ones or I have to write the code from scratch? You say that >> > I should create an offline scheduled indexer that update indexes >> > instead of the current contextual way? Is it the best way? >> >> As Ayende said, If the index file system is shared among all the >> backend servers, you can find problems whith the locking mechanism in >> network shares. And in the case it works, a bad performance because >> all the machines would need to compete for the write lock. As far as i >> know, neither Nhibernate nor Nhibernate.search provide a way to queue >> the updates to a master machine. >> >> The scheduled indexer is what we use, because having a central point >> for index writing is a big gain in performance and control in lucene. >> You could easily manage when to optimize the index, (a big gain in >> search performance and memory footprint again), and the updates are >> done in bigger batches, which is also better. If you can live with a >> small delay between the database is updated and the search results are >> updated, i think it is one of the bests solutions. >> >> You must also provide a way to refresh the indexreaders, as if i >> remember well, nhibernate search refresh them when you write something >> to the index. For example if your nlb doesn't send updates one of the >> backend machines, it will never refresh the indexreader and it will >> present stale results. >> >> -- >> Jokin > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "NHibernate Contrib - Development Group" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com.ar/group/nhcdevs?hl=en -~----------~----~----~----~------~----~------~--~---
