Database Concurrency

// Optimistic Locking in EF Core C# with Concurrency Tokens
//
// PURPOSE
// Optimistic concurrency detects whether a row changed between reading it and saving an edit. EF
// Core adds the original concurrency-token value to the UPDATE or DELETE predicate.
//
// The example uses an application-managed GUID token so the pattern can be demonstrated on
// PostgreSQL without pretending that SQL Server rowversion is a portable database feature.
//
// METHOD
// Configure Version with IsConcurrencyToken and ValueGeneratedNever. Return the version to the
// client when reading stock and require it on the next command.

// Pessimistic Locking in EF Core C# with PostgreSQL FOR UPDATE
//
// PURPOSE
// A pessimistic reservation acquires a database lock before checking and changing stock. This
// prevents two writers from both approving a reservation from the same pre-update quantity.
//
// EF Core tracks entities and saves changes, but tracking alone is not a concurrency lock. This
// PostgreSQL example explicitly combines a transaction with a parameterized SELECT FOR UPDATE.
//
// METHOD
// Create a fresh DbContext, begin a READ COMMITTED transaction, acquire the row lock, check
// availability, update the tracked entity, save, and commit.

# Optimistic Locking in Django with Versioned Updates and F Expressions
#
# PURPOSE
# Optimistic concurrency lets callers read without holding an application-level row lock for the
# entire edit. A later write succeeds only if the row still has the version the caller
# originally observed.
#
# The version is part of the update predicate, not just a value checked in Python. This closes
# the gap where another request could change the row after a Python comparison but before
# save().
#
# METHOD

# Pessimistic Locking in Django with select_for_update()
#
# PURPOSE
# Pessimistic locking acquires a database lock before reading the state used for a write. It is
# useful when a decision spans several checks or related changes and concurrent writers must
# take turns.
#
# Consider two requests reserving the last item. Reading available=1 and later saving
# available=0 in both requests can report two successful reservations. The example protects the
# read, stock check, and decrement as one transaction.
#
# METHOD