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 <[EMAIL PROTECTED]>: > 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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >
_______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
