Van Dang — Writing

Concurrency Control

Sun, 19 Jul 2026 00:00:00 GMT

Databases have long tried to hide concurrency issues from application developers by providing Transaction Isolation. In theory, isolation should make your life easier by letting you pretend that no concurrency is happening.

Read Uncommitted

This doesn’t provide any isolation (if yes, it will only prevent Dirty Write).

Weak Isolation Levels

Read Committed

This prevents:

Dirty writes:
- Definition: One client overwrites data that another client has written, but not yet committed. Almost all transaction implementations prevent dirty writes.
- Implementation: This can be implemented using row level lock.
Dirty reads:
- Definition: One client reads another client’s writes before they have been committed. The read committed isolation level and stronger levels prevent dirty reads.
- Implementation: This can also leverage the previously discussed lock. However, a long running write will cause other read-only queries to wait. A better approach would be to remember both old-committed value and newly-written-but-not-yet-committed value that holds the lock.

Snapshot Isolation - Repeatable Reads

Reads never block Writes and Vice Versa. Note: Repeatable Read is a term from SQL Standard - which is old (System R’s 1975 definition of isolation levels, the term “Snapshot isolation” hasn’t been invented yet), ambiguous, imprecise, and not as implementation-independent as a standard should be. Therefore there is confusion in “Repeatable Read” definition, and “Snapshot Isolation” implementations vary significantly.

These prevent:

Read skew (non-repeatable reads):
- Definition: A client sees different parts of the database at different points in time. This issue is most commonly prevented with snapshot isolation, which allows a transaction to read from a consistent snapshot at one point in time.
- Implementation: It is usually implemented with multi-version concurrency control (MVCC).
Lost updates:
- Definition: Two clients concurrently perform a read-modify-write cycle. One overwrites the other’s write without incorporating its changes, so data is lost.
- Implementation: some databases prevent this anomaly automatically (detects and aborts the transaction), some leverage atomic compare-and-set operation, while others require a manual lock (SELECT FOR UPDATE).

Strong Isolation Level - Serializability

This prevents:

Write skew:
- Definition: A transaction reads something, makes a decision based on the value it saw, and writes the decision to the database. However, by the time the write is made, the premise of the decision is no longer true. Only serializable isolation prevents this anomaly.
Phantom reads:
- Definition: A transaction reads objects that match some search condition. Another client makes a write that affects the results of that search. Snapshot isolation prevents straightforward phantom reads, but phantoms in the context of write skew require special treatment, such as index-range locks. There are 3 implementations (of 2 groups):

Pessimistic: Low performance
- Actual Serial Execution: Single Threaded, Serial order execution. Tips are:
  - Stored Procedure.
  - Partitioning.
  - Small and Fast transaction.
- Two Phases Locking - 2PL: Reads and Writes block each other. Widely used locks:
  - Predicate Lock.
  - Index Range Lock.
Optimistic - Serializable Snapshot Isolation (SSI): An integration between Snapshot Isolation and Two Phases Locking - 2PL - New and is getting more widely adopted
- All reads within a transaction are made from a consistent snapshot of a Database.
- Add algorithm to detect serialization conflicts among writes and which transactions to abort aka Decisions based on outdated premise.
  - Detecting stale MVCC reads: the database needs to track when a transaction ignores another transaction’s writes due to MVCC visibility rules. When the transaction wants to commit, the database checks whether any of the ignored writes have now been committed. If so, the transaction must be aborted.
  - Detecting writes that affect prior reads: use a similar locking technique from 2PL like Predicate Lock or Index Range Lock, except that SSI locks don’t block other transactions. When a transaction writes to the database, it must look in the indexes for any other transactions that have recently read the affected data. This process is similar to acquiring a write lock on the affected key range, but rather than blocking until the readers have committed, the lock acts as a tripwire: it simply notifies the transactions that the data they read may no longer be up to date.

Note

Due to the nature of detecting conflict and aborting the transaction, Clients under Snapshot Isolation and SSI schemes need to handle Conflict when being aborted.

Snapshot Isolation

Sun, 19 Jul 2026 00:00:00 GMT

A transaction executing under Snapshot Isolation appears to operate on a personal snapshot of the database, taken at the start of the transaction. When the transaction concludes, it will successfully commit only if the values updated by the transaction have not been changed externally since the snapshot was taken. Such a write–write conflict will cause the transaction to abort.

Two Phases Locking - 2PL

Sun, 19 Jul 2026 00:00:00 GMT

Two phases locking (2PL) the transactions handles its locking in 2 phases:

The expanding phase: No lock can be released
The shrinking phase: No lock can be acquired Locking rules are:
Read operations will be granted Shared Locks (meaning reads operations can be executed concurrently on the same item)
Write operations will be grant Exclusive Locks (meaning they are not compatible with any other operations regardless of their types) As this protocol can introduce Deadlock, it was extended to a variant called Conservative 2PL (C2PL), where transactions obtain all the locked required before actually beginning -> they won’t have to wait for other locks. However, due to its greediness, it often causes overhead in light-lock contention. Another variant, Strong strict two-phase locking (SS2PLP) put another constraint in which locks (regardless of type) are released only after transactions end. This implicitly renders the Protocol no longer “2 phases” by “removing phase 2”. This is the one being widely adopted due to its Serializability and Cascadeless Recoverability).

iVim - Vim for iPad

Sat, 20 Jan 2024 00:00:00 GMT

iVim is vim for iPad and is actually really good, as it (and its plugins, most of them) has already been compiled when installing (even plugins that are install in lua - lua nature). Therefore, most extensions work seamlessly on iPad. There are still many quirks when using this:

Some bug related to navigations because of iPad security (including syncing, symlinking, …)
Some extensions don’t work.
Lua and Python’s features limitation leading to Plugins not working properly.
Keyboard limitation on iPad (shameful 🙂).
Had to pay 140k VND for a built-in Plugin Manager as I am too tired manually installing them.
Couldn’t sync setting using iClouds. There are many OS-level interaction built-in Commands to use and interact with files from another place (e.g iCloud Drive) and many things more. The HowTo here helps a lot in setting this up. Some (not to say many) settings depend on iPadOS, therefore setting it in .vimrc just doesn’t work.