Also, if the only reason why you're committing is so a reader can see the changes (ie, you don't need so much "safety"), you should use IndexWriter.getReader instead.
commit is really only needed for safety (ie known recovery points on crash), or, for cases where the reader must be opened in a different JVM than the writer. Mike On Mon, Jan 11, 2010 at 4:57 AM, Michael McCandless <luc...@mikemccandless.com> wrote: > On Sun, Jan 10, 2010 at 6:13 PM, Sanne Grinovero > <s.grinov...@sourcesense.com> wrote: >> Even if it's not strictly needed anymore, could it improve performance? > > I think there should be no real performance gains/losses one way or another. > > The current updateDocument call basically boils down to delete then add. > >> Right now I need to use commit() right after this dual operation to >> make sure no reader is ever going to miss it > > You don't need to use commit() right after -- you can use commit any > time later and both the del & add will be present. > >> but if it was atomic I >> could have avoided the commit and just trust that "at some time later" >> it will be auto-committed: exact moment would be out of my control, >> but even so the view on index wouldn't have a chance to miss some >> documents. > > Lucene no longer auto-commits -- your app completely controls when to > commit, so, I think the atomic-ness is unecessary? > > Mike > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
