Excellent question, correct answer and explanation. This is something where people can easily go wrong, as some of the MS documentation is a bit confused.
Hany Helmy (9/3/2013)
I have to disagree with this answer as per MSDN:
"Transactions Durable: After the database engine acknowledges that a transaction has been committed, its changes are persistent in the database"; so we are talking here about Auto-Commit Transaction.
Also this: "Log records are written to disk when the transactions are committed" from your own reference in the answer; so Commit transactions first then Logging.
It doesn't say "the only time log records are flushed to disc is during the commit process"; rather obviously, if that were true the server would be unable to roll back partially complete transactions on restart after a failure (or it wouldn't need to, because all transactions had to keep all their data in RAM until commit time, so there could never be dirty pages on the disc - that would produce some pretty unpleasant effects on system limits).
Log records will be written to disc when any of the following things happen:
1) the lazy writer process asks for a dirty page to be flushed from the cache to disc and there are unflushed log records which contain undo information for that page. (I think SQL server doesn't bother to distinguish undo information from roll forward information so far as deciding to flush log records on page flush is concerned; in theory WAL but doesn't require the distinction to be made for that purpose.)
2) the checkpoint process asks for a dirty page to be flushed from cache to disc and there are unflushed log records which contain undo information for that page (same comment applies about the distinction.)
3) a user issues a commit command or a the server issues one automatically: here a commit record is added to the log cache before the flush; when the flush is complete, locks for the committing transaction are dropped and the commit is complete.
4) a rollback command is issued
5) a rollback is completed (this is not essential for durability, but it helps server startup performance)
6) initial (server startup) recovery is completed (this is not essential for durability, but it can help startup performance)
7) also at some points in backup, I think.
On a system running long transactions under really heavy store pressure, most log records will get to disc before the commit point of the transaction that caused them.