anchor.diff:  |===
   |Parameter |Valid Attributes |Description
   |`waitSearcher` |true, false |Block until a new searcher is opened and registered as the main query searcher, making the changes visible. Default is true.
  +|`OpenSearcher` |true, false |Open a new searcher making all documents indexed so far visible for searching. Default is true.
   |`softCommit` |true, false |Perform a soft commit. This will refresh the view of the index faster, but without guarantees that the document is stably stored. Default is false.
   |`expungeDeletes` |true, false |Valid for `commit` only. This parameter purges deleted data from segments. The default is false.
   |`maxSegments` |integer |Valid for `optimize` only. Optimize down to at most this number of segments. The default is 1.
  
positive.code: |===
  
  Use `maxDocs` and `maxTime` judiciously to fine-tune your commit strategies.
  
  [[NearRealTimeSearching-AutoCommits]]
  === AutoCommits
  
negative.code: [[NearRealTimeSearching-CommitsandOptimizing]]
  == Commits and Optimizing
  
  A commit operation makes index changes visible to new search requests. A *hard commit* uses the transaction log to get the id of the latest document changes, and also calls `fsync` on the index files to ensure they have been flushed to stable storage and no data loss will result from a power failure. The current transaction log is closed and a new one is opened. See the "transaction log" discussion below for data loss issues.
  
  A *soft commit* is much faster since it only makes index changes visible and does not `fsync` index files, or write a new index descriptor or start a new transaction log. Search collections that have NRT requirements (that want index changes to be quickly visible to searches) will want to soft commit often but hard commit less frequently. A softCommit may be "less expensive", but it is not free, since it can slow throughput. See the "transaction log" discussion below for data loss issues. 
  
  An *optimize* is like a *hard commit* except that it forces all of the index segments to be merged into a single segment first. Depending on the use, this operation should be performed infrequently (e.g., nightly), if at all, since it involves reading and re-writing the entire index. Segments are normally merged over time anyway (as determined by the merge policy), and optimize just forces these merges to occur immediately.
  
  