: > Right, if the updates come through IndexWriter or through a different : > IndexReader. But if you do the updates with an IndexReader (which : > eventually commits to disk), and also use that IndexReader for : > searching, we may need to synchronize? : : IMO, if we want to support something like that, we could make it so : the changes weren't visible until the next time the user called : getFieldCache() (which would have knowledge about the change and : create a new cache object, leaving the old object unaffected).
I wonder if this is a detail the Cache impls could worry about ... the Cache API could include hook methods for the IndexReader to notify it that various properties of the index have changed -- simple Cache impls used by people for "read only" indexes could makethese methods NOOPs and the accessors could be unsynchronized ... more complex impls could be written for more complex caches/usecases. (Incidently: i don't remember if it was in the orriginal patch, but one of my assumptions was that fieldNorm caching could be managed by this new API as well) -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]