lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mindaugas Žakšauskas <>
Subject Re: Lucene index architecture question
Date Thu, 26 Mar 2009 14:46:03 GMT
I don't think you can write to the same index (file) from multiple
locations at the same time and expect predictable behaviour.
Afficionados will correct me if I'm wrong, but I think pessimistic
locking file system (think NTFS) would simply not allow this,
optimistic locking (think ext3) would result either missing data in
the index files or (I suppose more likely) index corruption.

The solution we have built on Lucene uses event mechanism where every
node can inform any other node about changed record. Then the node
picks up the data from the primary information source. As you have
multi-node system, you probably need some sort of event/messaging
between nodes anyway, so why not just do it? Look at JMS, they've got
all sorts of facilities, e.g. serializing events into disk when the
remote node is down, etc.


On Thu, Mar 26, 2009 at 1:55 PM, kgeeva <> wrote:
> Thank you guys for the reply. Solr seems to be a good solution for
> distributed indexes but the app is already written with a Lucene index.
> So I had a question on Ian's answer as to going for 2 indexes.
> My app is on a weblogic cluster with two servers. The app is installed on
> both the servers.
> What are the issues I would have to deal with if I had only one index
> (located on one of the servers) and the second server would have a shared
> mapping to this index thus both servers are updating as well as searching
> from the same index. In this case I would have only one index to maintain.
> Are there any drawbacks to this architecture compared to the two index
> architecture?
> --
> Koshy

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message