Jason Rutherglen wrote:
A possible solution to FieldsReader is to have an
IndexReader.documents() method that returns a Documents class. The
Documents class maintains an underlying FieldsReader and file
descriptor that can be closed like TermEnum or TermDocs etc. Of
course it would have a document(int n, FieldSelector selector)
method. The issue is what the default behavior would be for
IndexReader.document for the SegmentReader.clone/reopen(boolean
force). I'm not sure how efficient it would be to open and close a
FieldsReader per IndexReader.document call.
I don't think we want to open/close FieldsReader per document() call?
I think we should test simply synchronizing FieldsReader, first. I
think that's the simplest solution. Modern JVMs have apparently
gotten better about synchronized calls, especially when there is
little contention. In the typical usage of Lucene there would be no
contention. If the performance cost is negligible then it makes
SegmentReader.doReopen very simple -- no external locking or special
subclassing is necessary.
I was using InstantiatedIndex and performing a commit when changes
came in, but realized that during the commit incoming searches could
see wrong results. Now, like the InstantiatedIndex javadocs
suggest, each one is immutable.
The IndexReader over the RAM buffer sounds good. As an interim
solution it would be beneficial to have the SegmentReader.clone/
reopen(boolean force) so that the first version of Ocean can be
completed and I can move on to other projects like Tag Index.
I agree we should still implement a SegmentReader.clone. Jason can
you update the patch? (change from boolean force to clone();
synchronization of FieldsReader; undoing the mixed up import line
shuffling).
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
