I like Uwe's idea. As for Hoss's original suggestion, my initial reaction is that if a user understands the need to set the option in the first place, they're also more likely to understand the need for close().
FWIW Erick On Tue, Mar 22, 2011 at 8:15 AM, Uwe Schindler <u...@thetaphi.de> wrote: > Hi, > >> I know there were good reasons for eliminating the "autoCommit" >> functionality from IndexWriter, but threads like tis make me thing thta > even >> though "autoCommit" on flush/merge/whatever was bad, having an option >> for some sort of "autoClose" using a finalizer might by a good idea to > give >> new/novice users a safety net. >> >> In the case of totally successful normal operation, this would result in > one >> commit at GC (assuming the JVM calls the finalizer) and if there were any >> errors it should (if i understnad correclty) do an implicit rollback. >> >> Anyone see a downside? > > I am against all finalizer stuff, because it also lead to problems and is > unreliable - we already removed all finalizer stuff in Lucene left over from > early day, so we should not add them again. This error done by this user is > only done once, the second time this user will have a try...finally block > around his stuff. > > A comparison is relational databases with autocommit off. If I crash my app > or don't correctly commit my stuff, it's also reverted on loose of > connection or foreful shutdown of JDBC driver! Where is the difference? > > But I am for adding a recovery tool for uncommitted segments to CheckIndex. > I this this should not be too hard. Something like looking for cfs/other > filetypes and creating SegmentReaders that are then added using addIndex(). > > Uwe > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
