(source discussion: http://colabti.org/irclogger/irclogger_log/monotone?date=2005-12-08,Thu&sel=90#l151)
Discussion of database locking in Monotone, problems and suggested solutions.
When monotone code needs to start a transaction, it instansiates
transaction_guard. By default this leads to execution
of the SQL statement BEGIN EXCLUSIVE. Transaction
guards can also be created in a non-exclusive mode; in this case
BEGIN DEFERRED is run. This should only be done if it
is believed no database writes will be performed.
We are trying to monotone bailing when a transaction involving
writes is committed. BEGIN EXCLUSIVE guarantees that
monotone will exit early and with a sensible error if unable to
gain a write lock on the database. However, it has the major
disadavantage that readers are excluded from the database for the
entire time the command is running.
Sqlite3 has several levels of locking. Some discussion has
occurred of switching to BEGIN IMMEDIATE rather than
BEGIN EXLUSIVE; only one process can hold an
IMMEDIATE lock but SHARED (reader) access is
still permitted. At the time of commit, IMMEDIATE
transitions to PENDING (no new readers) to EXCLUSIVE. The
amount of time readers are unable to access the DB is reduced,
however we still encounter the crash if there is a reader in the db
(see use case from NJS
below).
Sqlite does save us from dirty reads; a dirty read is seeing uncommitted writes in another transaction.
Use cases
- (from njs) e.g.,
monotone diff | less,<C-z>,monotone commit-> crash, db is locked - ViewMTN calls
monotone a lot, only to do reads. It can't access the db when the
database is being updated with
monotone pull.
Ways forward
15:22 <@njs> "In the current implementation, the RESERVED lock is also released, but that is not essential. Future versions of SQLite might provide a "CHECKPOINT" SQL command that will commit all changes made so far within a transaction but retain the RESERVED lock so that additional changes can be made without given any other process an opportunity to write."
15:22 <@njs> ^^ sounds like what we've been wanting...
Reference: