: Solr sounds very interesting though - how do you maintain the cache? : Are you storing filters? And how do you persist these, via the session : or using some kind of register? I was considering designing something : like this but felt that state management was something I wanted to avoid : doing if possible, because it limits how many users we can service, if a : lot of data is being kept round for caching. Would be very interested : in how you managed to do this, and still make Solr scalable.
this question would probably make more sense on the solr-user mailing list, but the short answer is: No session state, just Caches of Query=>DocSet when scoring isn't used, and Query => DocList (when scoring is used). The caches are maintained on a per searcher basis, and a single searcher is used to serve all requests untill a "commit" is made, a new searcher is opened and it's caches are "warmed" using the keys of the old searchers cache before any user queries are sent to it. (A DocSet is like a BitSet, but there is support for alternate compact representations when the number of docs is small, a DocList is a "window" into ordered results -- think a single page of paginated results) -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
