Yes I agree, good catch.
Additionally I could add some minor performance improvement
using a background thread in SharingBufferReaderProvider,
(to have the file-closing operations of unneeded segments run async)
but didn't implement that as I was lacking a shutdown hook.
But DirectoryProvider(s) are doing the same stuff using a "stop()" method,
however I like the "destroy()" name more.
I think for consistency they should be named the same.
As the "stop" feature for DirectoryProviders is new in Search 3.1,
maybe it's still ok to change it's name?
Sanne
2008/7/19 Emmanuel Bernard <emmanuel(a)hibernate.org>:
Should we need a readerProvider.destroy()?
ReaderProvider typically keep IndexReaders open till they are in use or if
the index has been updated. But it has no hook to close the "current"
IndexReaders when Hibernate Search goes down.
I imagine the current code can become problematic on some VMs if we do lots
of hot redeployments.
--
Emmanuel Bernard
http://in.relation.to/Bloggers/Emmanuel |
http://blog.emmanuelbernard.com
|
http://twitter.com/emmanuelbernard
Hibernate Search in Action (
http://is.gd/Dl1)
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev