Yonik Seeley wrote on 01/16/2007 11:29 AM: > On 1/16/07, robert engels <[EMAIL PROTECTED]> wrote: >> You have the same problem if there is an existing reader open, so >> what is the difference? You can't remove the segments there either. > > The disk space for the segments is currently removed if no one has > them open... this is quite a bit different than guaranteeing that a > reader in the future will be able to open an index in the past.
To me the key benefit of explicit commits is that ongoing adds and their associated merges update only the segments of the current snapshot. The current snapshot can be aborted, falling back to the last checkpoint without having made any changes to its segments at all. Once a commit is done the committed snapshot becomes the new checkpoint. Lucene does not have this desirable property now even for adding a single document, since that document may cause a merge with consequences arbitrarily deep into the index. For the single-transaction use case it is only necessary that the segments in the current checkpoint and those in the current snapshot are maintained. Revising the current snapshot can delete segments in the prior snapshot, and committing can delete segments in the prior checkpoint. Of course support for multiple parallel transactions would be even better, but is also a huge can of worms as anyone who has spent time chasing database deadlocks and understanding all the different types of locks that modern databases use can attest. The single-transaction case seems straightforward to implement per Michael's suggestion and enables valuable use cases as the thread has enumerated. Chuck --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
