Index: pages/atomiccommit.in ================================================================== --- pages/atomiccommit.in +++ pages/atomiccommit.in @@ -30,11 +30,11 @@

The information in this article applies only when SQLite is operating in "rollback mode", or in other words when SQLite is not using a [write-ahead log]. SQLite still supports atomic commit when write-ahead logging is enabled, but it accomplishes atomic commit by -a different mechanism from the one describe in this article. See +a different mechanism from the one described in this article. See the [WAL | write-ahead log documentation] for additional information on how SQLite supports atomic commit in that context.

hd_fragment hardware

2.0 Hardware Assumptions

@@ -160,11 +160,11 @@ SQLite assumes that the data it reads is exactly the same data that it previously wrote.

By default, SQLite assumes that an operating system call to write a range of bytes will not damage or alter any bytes outside of that range -even if a power lose or OS crash occurs during that write. We +even if a power loss or OS crash occurs during that write. We call this the "[PSOW | powersafe overwrite]" property. Prior to version 3.7.9, SQLite did not assume powersafe overwrite. But with the standard sector size increasing from 512 to 4096 bytes on most disk drives, it has become necessary to assume powersafe overwrite in order to maintain historical performance levels and so powersafe overwrite is assumed by @@ -224,11 +224,11 @@ another database connection from writing to the database file while we are reading it. This is necessary because if another database connection were writing to the database file at the same time we are reading from the database file, we might read some data before the change and other data after the change. -This would make it appears as if the change made by the other +This would make it appear as if the change made by the other process is not atomic.

Notice that the shared lock is on the operating system disk cache, not on the disk itself. File locks really are just flags within the operating system kernel, @@ -275,11 +275,11 @@ locks from other processes. However, there can only be a single reserved lock on the database file. Hence only a single process can be attempting to write to the database at one time.

-

The idea behind a reserved locks is that it signals that +

The idea behind a reserved lock is that it signals that a process intends to modify the database file in the near future but has not yet started to make the modifications. And because the modifications have not yet started, other processes can continue to read from the database. However, no other process should also begin trying to write to the @@ -404,11 +404,11 @@ database changes are written into nonvolatile storage. This is a critical step to ensure that the database will survive a power loss without damage. However, because of the inherent slowness of writing to disk or flash memory, this step together with the rollback journal file flush in section -3.7 above takes up most the time required to complete a +3.7 above takes up most of the time required to complete a transaction commit in SQLite.


3.11 Deleting The Rollback Journal

@@ -417,11 +417,11 @@

After the database changes are all safely on the mass storage device, the rollback journal file is deleted. This is the instant where the transaction commits. If a power failure or system crash occurs prior to this point, then recovery processes to be described later make -it appears as if no changes were ever made to the database +it appear as if no changes were ever made to the database file. If a power failure or system crash occurs after the rollback journal is deleted, then it appears as if all changes have been written to disk. Thus, SQLite gives the appearance of having made no changes to the database file or having made the complete set of changes to the @@ -501,21 +501,23 @@ hd_fragment crisis

4.1 When Something Goes Wrong...

-

Suppose the power loss occurred during step 3.10 above, +

Suppose the power loss occurred +during step 3.10 above, while the database changes were being written to disk. After power is restored, the situation might be something like what is shown to the right. We were trying to change three pages of the database file but only one page was successfully written. Another page was partially written and a third page was not written at all.

The rollback journal is complete and intact on disk when the power is restored. This is a key point. The reason for -the flush operation in step 3.7 is to make absolutely sure that +the flush operation in step 3.7 +is to make absolutely sure that all of the rollback journal is safely on nonvolatile storage prior to making any changes to the database file itself.


@@ -522,11 +524,12 @@

4.2 Hot Rollback Journals

The first time that any SQLite process attempts to access the database file, it obtains a shared lock as described in -section 3.2 above. But then it notices that there is a +section 3.2 above. +But then it notices that there is a rollback journal file present. SQLite then checks to see if the rollback journal is a "hot journal". A hot journal is a rollback journal that needs to be played back in order to restore the database to a sane state. A hot journal only exists when an earlier process was in the middle of committing @@ -534,11 +537,11 @@

A rollback journal is a "hot" journal if all of the following are true: