On 8/9/06, Oliver Hutchison <[EMAIL PROTECTED]> wrote:
Yonik,
> most easily implemented in Java5 via Future.
I didn't use Java5 as I had a feeling that code is Lucene needs to compile
on Java1.3 right?
Lucene 2 currently requires Java 1.4
It was really just a side comment - people have implemented these
blocking maps before, and I've seen it done with Java5 concurrency
things like Future - a natural fit. The way you were going about it
is perfectly fine though.
> I don't think you need two maps though, right? just stick a
> placeholder in the outer map.
I'm using 2 maps mainly because it simplifies the implementation.
Technically all that is needed is a singe map with a key that is a composite
of index reader and field name however, given that there is also the
requirement that we only maintain a weak reference to the index reader and
the associated need to clean up the cache if the reader gets gc'd, it was
simpler for me to simulate the composite key using the 2 maps.
Ah, right... I browsed your code a bit too fast. It looks fine.
On a related note it would be great if there was a way to plug a custom
FieldCache implementation into Lucene, given there is a FieldCache interface
it's a shame there's no way to actually provide an alternative
implementation.
Well, there's FieldCache.DEFAULT
/** Expert: The cache used internally by sorting and range query classes. */
public static FieldCache DEFAULT = new FieldCacheImpl();
-Yonik
http://incubator.apache.org/solr Solr, the open-source Lucene search server
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
