lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: lucene and ejb applications
Date Fri, 20 Aug 2004 16:02:01 GMT
On Aug 20, 2004, at 7:54 AM, Rupinder Singh Mazara wrote:
> hi erik
>  thanks for the warning and the code.
>  Let me re-phrase the question,
>  i have a index generated by lucene, i need to have the search 
> capabilty
>  to have a high availabilty. What solutions would be the most optimal

I'm guessing from your descriptions that you want a search server that 
multiple applications can access.  Correct?  Is that what you mean by 
"high availability"?

Take a look at Nutch for examples of doing this kind of thing.  And 

>  Currentlly i have two senarions in mind
>   a) setup a RMI based app. that on start-up initializes a 
> IndexSearcher
> object
>      and waits for invocation of a method like Vector 
> executeQuery(Query )

Lucene has built-in RMI capability, so you don't need to recreate this 
yourself.  Look at RemoteSearchable (and the test cases that use it).

>   b) create a web based app(jsp/servlet or struts)  that initialises 
> the
> IndexSearcher object, and stores in the servletContext on 
> intialization, and
> all request invoke the Hits search(Query q)

This is ok, but you have the same issues with servlet context 
(application scope or even session scope) with distributed 
applications.  IndexSearcher, at the very least, should be transient 
and lazy initialized, perhaps nested under a controller object of your 

>   with senario a)  i can have more control over updates, insert, and 
> deletes
>   where as with  senario b) has higher availabilty

I disagree with your analysis of those scenarios.  Neither has more or 
less control or availability than the other.

>  I want to create and store the IndexSearcher object, during 
> initailization
> to save on
>  mutlitple open and reads. once updates are ready signal can be sent to
> block further searches while the updates are integrated into the 
> existing
> index.

It is a good thing to keep an IndexSearcher instance around for big 
indexes to save on that I/O, I completely agree.  A simple 
IndexSearcher-encapsulating Java object which lazy initializes and 
keeps IndexSearcher as a transient would be quite sufficient, I think.  
Store that object wherever you like - application scope seems to be 
appropriate for your web application scenario.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message