EJB solution for Lucene

[Jeff Wilson <jw...@hotmail.com>]

Hi,

I'm interested in a Lucene EJB solution with JDBC, possibly using something 
like the SQLDirectory from Marc Kramis at 
http://www.mail-archive.com/lucene-user@jakarta.apache.org/msg00416.html.  
How has such an EJB usage been implemented by other users?  What happened to 
the performance when replacing file system storage with database storage?
Anyone who has been down this road before please share a map of the terrain.

Thanks.
Jeff

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: EJB solution for Lucene

["Steven J. Owens" <pu...@darksleep.com>]

Jeff wrote:
> I'm interested in a Lucene EJB solution with JDBC, possibly using
> something like the SQLDirectory from Marc Kramis at
>
> http://www.mail-archive.com/lucene-user@jakarta.apache.org/msg00416.html.  
>
> How has such an EJB usage been implemented by other users?  What
> happened to the performance when replacing file system storage with
> database storage?  Anyone who has been down this road before please
> share a map of the terrain.

     I haven't been down this road.  I'm not sure why I'd *want* to go
down this road, except, perhaps, to provide a singleton-style solution
in a J2EE context by using an entity bean.  (I'm *still* not really
happy with this approach, there should be a better way to do a
singleton under servlet spec 2.3 without running afoul of multi-JVM
issues, but that's neither here nor there).

     Using container-managed persistence would be pointless for this
specific purpose.  With bean-managed-persistence, presumably
performance would be about the same as using SQLDirectory by itself,
plus the usual RMI overhead for each call, incurred with J2EE
solutions.  If you did take this route, I strongly suggest you SHOULD
NOT you create a hits entity bean and return a reference to it.
There's a lot of RMI overhead per method call, and J2EE does not do
anything clever about optimizing it.  Instead, return the hits object
as a serialized object.  Or better yet, do your preprocessing of the
hits object on the EJB side and return a preprocessed object
representing your search results.

Steven J. Owens
puff@darksleep.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>