so, you mean, I open one reader for each session (each user) and never close it until the session has expired? if I do this, is that affect the performance?
On 2/25/07, Mark Miller <[EMAIL PROTECTED]> wrote:
If you never modify your index you should never need to close your reader (or searcher). Doing so would just slow you down. Mohammad Norouzi wrote: > Hi > actually I dont have any writer or writing reader. I just have reader. > when > a reader is created by the user because the document returned by hits is > very much, for example 20,000 so I display the result page by page. > whenever > user click to next page the hits will use the reader to load next 20 > records, > besides, I dont have one directory, there are more than one directory and > index on the server and each user may request for one of them. > the problem is, a user may close his browser window and the reader > will stay > open becasue I cant detect it. and either if his session expires my > destroy > method will be called and searcher will close but in the cached > searcher i > can not detect which one is closed and ready it for next user. if the > searcher had a isClosed() method it was easy to determine but > unfortunately > it's has'nt > > any idea? > thanks again > > On 2/25/07, Mark Miller <[EMAIL PROTECTED]> wrote: >> >> I am a bit confused about what you are asking. Why do you need the >> Searcher to time out? That code should release your searchers at the >> appropriate times...when the index has been modified. The way that I use >> it is to make a synchronized map that keeps around an index accessor for >> each index that I open...from there the code should do the rest...when a >> writer or a writing reader is released the code waits for all searchers >> to be released and then clears the cache of searchers and new searchers >> are created when requested until another writer or writing reader is >> released... >> >> Mohammad Norouzi wrote: >> > Thank you Mark for your useful help. the code you introduce was very >> > helpful >> > for me >> > >> > but my only question is that I need to place an idle time for each >> open >> > searcher, so if it exceed the specific time then release that searcher >> > and >> > get ready for another thread. >> > >> > how can I put such this feature, I was thinking of a timeout listener, >> > but >> > dont know where tu put it. I have a SingleSearcher that wraps lucene's >> > Searcher and it returns an ResultSet in which I put a Hits object. do >> > I have >> > to put the time in my ResultSet or my SingleSeacher? >> > >> > still I dont know ehrthrt the reader is important for Hits or >> Searcher? >> > consider I passed a hits to my ResultSet, now, if I close searcher, >> > will the >> > Reader get closed? or another vague thing is can a Reader work thread >> > safely for every Searcher with differenet queries? >> > >> > Thank you very much again. >> > >> > On 2/22/07, Mark Miller <[EMAIL PROTECTED]> wrote: >> >> >> >> I would not do this from scratch...if you are interested in Solr go >> that >> >> route else I would build off >> >> http://issues.apache.org/jira/browse/LUCENE-390 >> >> >> >> - Mark >> >> >> >> Mohammad Norouzi wrote: >> >> > Hi all, >> >> > I am going to build a Searcher pooling. if any one has >> experience on >> >> > this, I >> >> > would be glad to hear his/her recommendation and suggestion. I want >> to >> >> > know >> >> > what issues I should be apply. considering I am going to use >> this on >> a >> >> > web >> >> > application with many user sessions. >> >> > >> >> > thank you very much in advance. >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Regards, Mohammad
