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: [email protected] For additional commands, e-mail: [email protected]
