lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Praveen Peddi" <ppe...@contextmedia.com>
Subject Re: lucene and ejb applications
Date Fri, 20 Aug 2004 16:11:53 GMT
Infact we do the same exact thing. Session bean method called search()
delegates to a POJO SearchService. We lazy load the IndexSearch cache it in
memory and invalidate that object when someone else modifies the index. This
trick works wonderfually for us. The search has become faster after caching
the searcher.

Praveen
----- Original Message ----- 
From: "Erik Hatcher" <erik@ehatchersolutions.com>
To: "Lucene Users List" <lucene-user@jakarta.apache.org>
Sent: Friday, August 20, 2004 12:02 PM
Subject: Re: lucene and ejb applications


> 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
> also...
>
> >
> >  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
> making.
>
> >   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.
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-user-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org


Mime
View raw message