lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: Trying to understand soft vs hard commit vs transaction log
Date Sat, 09 Feb 2013 02:13:52 GMT
A soft commit is just like a hard commit but doesn't do things like resolve deletes or call
fsync on all the files that were written to disk. It will flush to disk however.

Hard commits are for durability if you are not using the update log. If you are using the
update log, hard commits are about flushing the update log to disk (eg keeping update log
RAM usage down).

Soft commits are more about visibility - because it won't do things like fsync, it won't guarantee
that segment that was flushed to disk will survive a hard crash, but it will flush to disk
and open a new view on that flushed segment.

- Mark

On Feb 7, 2013, at 11:29 PM, Alexandre Rafalovitch <> wrote:

> Hello,
> What actually happens when using soft (as opposed to hard) commit?
> I understand somewhat very high-level picture (documents become available
> faster, but you may loose them on power loss).
> I don't care about low-level implementation details.
> But I am trying to understand what is happening on the medium level of
> details.
> For example what are stages of a document if we are using all available
> transaction log, soft commit, hard commit options? It feels like there is
> three stages:
> *) Uncommitted (soft or hard): accessible only via direct real-time get?
> *) Soft-committed: accessible through all search operatons? (but not on
> disk? but where is it? in memory?)
> *) Hard-committed: all the same as soft-committed but it is now on disk
> Similarly,  in performance section of Wiki, it says: "A commit (including a
> soft commit) will free up almost all heap memory" - why would soft commit
> free up heap memory? I thought it was not flushed to disk.
> Also, with soft-commits and transaction log enabled, doesn't transaction
> log allows to replay/recover the latest state after crash? I believe that's
> what transaction log does for the database. If not, how does one recover,
> if at all?
> And where does openSearcher=false fits into that? Does it cause
> inconsistent results somehow?
> I am missing something, but I am not sure what or where. Any points in the
> right direction would be appreciated.
> Regards,
>     Alex.
> Personal blog:
> LinkedIn:
> - Time is the quality of nature that keeps events from happening all at
> once. Lately, it doesn't seem to be working.  (Anonymous  - via GTD book)

View raw message