Hubbry Logo
Record lockingRecord lockingMain
Open search
Record locking
Community hub
Record locking
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Record locking
Record locking
Record locking
View on Wikipedia
from Wikipedia

Record locking is the technique of preventing simultaneous access to data in a database, to prevent inconsistent results.

The classic example is demonstrated by two bank clerks attempting to update the same bank account for two different transactions. Clerks 1 and 2 both retrieve (i.e., copy) the account's record. Clerk 1 applies and saves a transaction. Clerk 2 applies a different transaction to his saved copy, and saves the result, based on the original record and his changes, overwriting the transaction entered by clerk 1. The record no longer reflects the first transaction, as if it had never taken place.

A simple way to prevent this is to lock the file whenever a record is being modified by any user, so that no other user can save data. This prevents records from being overwritten incorrectly, but allows only one record to be processed at a time, locking out other users who need to edit records at the same time.

To allow several users to edit a database table at the same time and also prevent inconsistencies created by unrestricted access, a single record can be locked when retrieved for editing or updating. Anyone attempting to retrieve the same record for editing is denied write access because of the lock (although, depending on the implementation, they may be able to view the record without editing it). Once the record is saved or edits are canceled, the lock is released. Records can never be saved so as to overwrite other changes, preserving data integrity.

In database management theory, locking is used to implement isolation among multiple database users. This is the "I" in the acronym ACID.

A thorough and authoritative description of locking was written by Jim Gray.[1]

Granularity of locks

[edit]

If the bank clerks (to follow the illustration above) are serving two customers, but their accounts are contained in one ledger, then the entire ledger, or one or more database tables, would need to be made available for editing to the clerks in order for each to complete a transaction, one at a time (file locking). While safe, this method can cause unnecessary waiting.

If the clerks can remove one page from the ledger, containing the account of the current customer (plus several other accounts), then multiple customers can be serviced concurrently, provided that each customer's account is found on a different page than the others. If two customers have accounts on the same page, then only one may be serviced at a time. This is analogous to a page-level lock in a database.

A higher degree of granularity is achieved if each individual account may be taken by a clerk. This would allow any customer to be serviced without waiting for another customer who is accessing a different account. This is analogous to a record-level lock and is normally the highest degree of locking granularity in a database management system.

In a SQL database, a record is typically called a "row".

The introduction of granular (subset) locks creates the possibility for a situation called deadlock. Deadlock is possible when incremental locking (locking one entity, then locking one or more additional entities) is used. To illustrate, if two bank customers asked two clerks to obtain their account information so they could transfer some money into other accounts, the two accounts would essentially be locked. Then, if the customers told their clerks that the money was to be transferred into each other's accounts, the clerks would search for the other accounts but find them to be "in use" and wait for them to be returned. Unknowingly, the two clerks are waiting for each other, and neither of them can complete their transaction until the other gives up and returns the account. Various techniques are used to avoid such problems.

Use of locks

[edit]

Record locks need to be managed between the entities requesting the records such that no entity is given too much service via successive grants, and no other entity is effectively locked out. The entities that request a lock can be either individual applications (programs) or an entire processor.

The application or system should be designed such that any lock is held for the shortest time possible. Data reading, without editing facilities, does not require a lock, and reading locked records is usually permissible.

Two main types of locks can be requested:

Exclusive locks

[edit]

Exclusive locks are exclusively held by a single entity, usually for the purpose of writing to the record. If the locking schema was represented by a list, the holder list would contain only one entry. Since this type of lock effectively blocks any other entity that requires the lock from processing, care must be used to:

  • ensure the lock is held for the shortest time possible;
  • not hold the lock across system or function calls where the entity is no longer running on the processor – this can lead to deadlock;
  • ensure that if the entity is unexpectedly exited for any reason, the lock is freed.

Non-holders of the lock (a.k.a. waiters) can be held in a list that is serviced in a round-robin fashion, or in a FIFO queue. This would ensure that any possible waiter would get equal chance to obtain the lock and not be locked out. To further speed up the process, if an entity has gone to sleep waiting for a lock, performance is improved if the entity is notified of the grant, instead of discovering it on some sort of system timeout driven wake-up.

Shared locks

[edit]

Shared locks differ from exclusive locks in that the holder list can contain multiple entries. Shared locks allow all holders to read the contents of the record knowing that the record cannot be changed until after the lock has been released by all holders. Exclusive locks cannot be obtained when a record is already locked (exclusively or shared) by another entity.

If lock requests for the same entity are queued, then once a shared lock is granted, any queued shared locks may also be granted. If an exclusive lock is found next on the queue, it must wait until all shared locks have been released. As with exclusive locks, these shared locks should be held for the least time possible.

See also

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Record locking

View on Grokipedia
from Grokipedia
Record locking is a fundamental mechanism in database management systems (DBMS) that restricts simultaneous access to individual data records by multiple transactions, preventing conflicts such as lost updates, dirty reads, or non-repeatable reads to maintain and consistency. By applying locks at the record or row level, it ensures that only one transaction can modify a specific record at a time, while allowing concurrent reads in some configurations, thereby balancing performance and reliability in multi-user environments. There are two primary approaches to record locking: pessimistic and optimistic. Pessimistic locking acquires an exclusive lock on a record before any read or modification operation, blocking other transactions from accessing it until the lock is released at transaction commit or , which is particularly useful in high-contention scenarios to avoid conflicts proactively. In contrast, optimistic locking permits multiple transactions to read and potentially modify records concurrently without initial locks, but detects and resolves conflicts at commit time by verifying if the record has changed (e.g., via version numbers or timestamps), rejecting updates if inconsistencies are found. Lock types further refine this control, including shared locks for read operations that allow multiple concurrent readers but block writers, and exclusive locks that permit neither reads nor writes by others during modifications. In systems like SQL Server, locks can escalate from fine-grained row-level to coarser page or table levels to optimize usage, while mechanisms such as ensure serializability by acquiring all locks before releasing any. These features are implemented across various DBMS, including , , and OpenEdge, adapting to specific isolation levels like READ COMMITTED or SERIALIZABLE to suit application needs.

Fundamentals

Definition and Purpose

Record locking is a mechanism employed in database management systems and file systems to prevent multiple transactions from simultaneously accessing or modifying the same data record, thereby avoiding conflicts and ensuring . By restricting concurrent access, record locking serializes operations on shared resources, which is essential in multi-user environments where transactions must execute as if they were isolated from one another. This technique is particularly vital in relational databases, where records represent individual rows in tables, but it also applies to file-based systems handling structured data. The primary purpose of record locking is to uphold the properties of database transactions—specifically atomicity, consistency, isolation, and —with a strong emphasis on isolation and consistency. Isolation ensures that transactions do not interfere with each other, preventing phenomena such as dirty reads or lost updates, while consistency guarantees that the database remains in a valid state after each transaction. For example, consider two transactions attempting to debit and credit the same account balance concurrently: without locking, the second transaction might overwrite the first's changes, resulting in a lost update and an inaccurate balance. Record locking mitigates this by enforcing during critical sections of transaction execution. At its core, the mechanics of record locking involve a transaction requesting and acquiring a lock on a specific record prior to any read or write operation, holding it until the transaction commits or aborts, at which point the lock is released to allow subsequent access. This process effectively queues conflicting operations, promoting a serializable execution order without requiring full serialization of all transactions. Locks may be implemented at varying granularities, from individual records to larger structures like pages or tables, and can include both exclusive modes for modifications and shared modes for reads, depending on the system's design. The foundational principles of this approach were articulated by Jim Gray and Andreas Reuter in their authoritative text Transaction Processing: Concepts and Techniques (1993), which establishes locking as a cornerstone of reliable in distributed and centralized systems.

Historical Development

The concept of record locking emerged in the late 1960s and early 1970s as database systems began supporting multi-user access to shared data. IBM's Information Management System (IMS), a hierarchical developed starting in 1966, introduced record-level locking to isolate changes made by concurrent programs, enabling reliable in environments like banking and airlines. Concurrently, the shift toward relational databases was catalyzed by Edgar F. Codd's 1970 paper, which proposed a model for large shared data banks, implying the need for mechanisms to maintain amid multiple users. IBM's System R project (1974–1979), the first implementation of Codd's , incorporated locking protocols as part of its transaction management, using to ensure serializability in multi-user scenarios. In the late 1970s and 1980s, foundational work by Jim Gray and colleagues at formalized record locking within frameworks. Gray's contributions during the System R era and subsequent projects introduced the transaction abstraction, including the properties of atomicity, consistency, isolation, and durability—later known as the properties—with locking as a core mechanism for achieving isolation through protocols like . This work extended to distributed systems, where Gray's research in the 1980s addressed locking in non-shared environments, such as at , influencing scalable concurrency in transaction-oriented applications. These advancements laid the groundwork for standardized approaches, culminating in the ANSI standard (1992), which defined isolation levels (READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, and SERIALIZABLE) that rely on locking modes to control concurrency phenomena like dirty reads and phantoms. The and saw a shift toward finer-grained locking to improve concurrency in management systems (RDBMS). Oracle 6.0, released in 1988, pioneered row-level locking, allowing multiple users to access the same table without blocking unrelated rows, a feature that enhanced performance in high-throughput environments. Similarly, Microsoft SQL 7.0 (1998) adopted row-level locking as its default, moving away from coarser page- or table-level mechanisms to reduce contention in enterprise applications.

Types of Locks

Exclusive Locks

An exclusive lock is a lock mode in database systems that grants a single transaction sole access to a record or resource for modification purposes, thereby blocking all other transactions from writing to that resource until the lock is released, and in many systems such as SQL Server and DB2, also blocking reads. This mode ensures that data modifications occur without interference, maintaining the integrity of the data during write operations. Exclusive locks are essential for update and delete operations, as they prevent issues such as dirty reads—where a transaction reads uncommitted changes from another—or lost updates, where concurrent modifications overwrite each other. In systems like SQL Server and DB2, they are typically acquired automatically during data-modifying statements to enforce isolation. These locks are acquired either explicitly through commands like SQL's LOCK statement or implicitly as part of a transaction's execution, and they are held until the transaction commits—making changes permanent—or rolls back—discarding them. For instance, in , an EXCLUSIVE lock conflicts with most other lock modes except basic read access (ACCESS SHARE locks), ensuring no concurrent writes occur while allowing reads. A practical example is in a banking , where an exclusive lock is placed on an account record during a fund transfer to debit one account and another, guaranteeing atomicity and preventing balance inconsistencies from simultaneous transactions. While exclusive locks reduce concurrency by serializing access to the locked resource—potentially impacting performance in high-throughput environments—they provide strong guarantees of serializability for modifications, ensuring that committed changes appear as if executed sequentially. Unlike shared locks, which permit multiple readers but no writers, exclusive locks block writes and, in many s, all access to prioritize safe writes. Their impact varies with , such as row-level locking allowing finer parallelism than table-level.

Shared Locks

Shared locks, also known as read locks, are a lock mode in database that permits multiple transactions to simultaneously read a specific record or while preventing any transaction from writing to it. This mode ensures that readers do not interfere with each other but collectively block writers to maintain data consistency during concurrent access. Shared locks are particularly suited for workloads dominated by read operations, such as reporting queries or SELECT statements that retrieve data without modification. In such scenarios, they enable high concurrency among read-only transactions, optimizing throughput in systems where queries outnumber updates. A key behavior of shared locks is their potential upgrade to exclusive locks when a transaction requires write access; however, this conversion can only proceed after all conflicting shared locks on the resource are released. For instance, in an database, multiple users can acquire shared locks to view current inventory levels simultaneously, but any attempt to update stock quantities would require upgrading to an exclusive lock, blocking until all shared locks are freed. Regarding compatibility, shared locks can coexist with other shared locks but are incompatible with exclusive locks, as shown in the following matrix for basic lock modes:
Lock ModeShared (S)Exclusive (X)
Shared (S)CompatibleIncompatible
Exclusive (X)IncompatibleIncompatible
Shared locks play a role in supporting read-committed isolation levels by protecting reads and preventing dirty reads, though they allow non-repeatable reads.

Granularity of Locks

Coarse-Grained Locking

Coarse-grained locking refers to a mechanism in database systems where locks are applied to larger units of , such as entire tables, pages, files, or even databases, rather than to individual records. This approach minimizes the number of locks that need to be managed, thereby reducing the overhead associated with acquiring, releasing, and tracking numerous fine-level locks. In shared database environments, coarse-grained locks are particularly useful for maintaining consistency during operations that affect broad scopes of , as they simplify the locking protocol by associating locks with sets of resources rather than atomic elements. The primary advantages of coarse-grained locking emerge in environments with low concurrency, such as systems serving few simultaneous users or handling bulk operations like data imports or schema modifications. In these scenarios, the reduced lock management cost leads to lower overhead and simpler , as fewer locks mean less contention and easier enforcement of isolation. For instance, a transaction accessing many records within a single table benefits from locking the entire table, avoiding the expense of multiple individual locks while ensuring atomicity. This makes coarse-grained locking efficient for workloads where high parallelism is not required, such as in early database designs or applications with infrequent concurrent access. Examples of coarse-grained locking include table-level locks in , which are employed for (DDL) statements to protect structural changes across the entire table, preventing concurrent modifications that could lead to inconsistencies. Similarly, traditional file systems often use whole-file locks to guard against simultaneous writes, treating the file as the lockable unit to simplify in non-relational storage environments. Both exclusive and shared locks can be applied at these coarse levels; for example, an exclusive table lock blocks all access, while a shared lock permits multiple reads but no writes. However, coarse-grained locking introduces trade-offs by restricting concurrency, as locking a large unit like a table can block operations on unrelated records within it, leading to unnecessary serialization in multi-user settings. This makes it suitable primarily for online transaction processing (OLTP) systems with low contention, where the simplicity outweighs the potential for bottlenecks. In contrast to fine-grained locking, which permits higher parallelism through record-specific controls, coarse-grained methods prioritize ease of management over maximal throughput. Historically, coarse-grained locking was prevalent in early hierarchical databases, such as IBM's Information Management System (IMS), which employed a two-level locking at the database and segment levels to isolate concurrent program changes with minimal overhead. This approach, developed in the , reflected the hardware and workload constraints of the era, where fine-grained mechanisms were computationally expensive, and broader locks sufficed for batch-oriented processing. Seminal work on lock , including proposals for hierarchical protocols, built upon these systems to balance concurrency and efficiency in shared environments.

Fine-Grained Locking

Fine-grained locking refers to a mechanism in database systems where locks are applied at the individual record or row level, permitting concurrent access to unrelated portions of the data while preventing conflicts on the targeted rows. This approach contrasts with broader locking strategies by isolating modifications to specific rows, thereby allowing multiple transactions to proceed simultaneously on different records within the same table. In multi-user (OLTP) environments, fine-grained locking enhances throughput by reducing the scope of blocked operations, enabling higher levels of concurrency as transactions affecting distinct rows do not interfere with one another. This granularity supports scalable applications where frequent, short-lived updates occur across large datasets, minimizing wait times and improving overall system responsiveness. A practical example is row-level locking in , where commands like SELECT * FROM table WHERE id = 1 FOR UPDATE acquire an exclusive lock on a single row to facilitate selective updates in large tables without impacting other records. This mechanism applies both exclusive modes, such as FOR UPDATE to block modifications, and shared modes, like FOR SHARE to allow reads while restricting writes. However, fine-grained locking introduces challenges, including increased overhead from managing a larger number of locks, which can consume more system resources and complicate lock administration. Additionally, the finer interactions among transactions heighten the risk of deadlocks, as cycles in lock dependencies become more likely with numerous row-specific acquisitions. Fine-grained locking, particularly row-level variants, became a standard feature in relational database management systems during the late 1980s and 1990s to accommodate the growing demands of concurrent, scalable applications, as exemplified by its introduction in Oracle Database version 6 in 1988.

Implementation Considerations

In Database Systems

In relational database management systems (RDBMS), record locking ensures data consistency during concurrent transactions by preventing conflicting access to data rows. Modern RDBMS such as Oracle, SQL Server, and PostgreSQL implement locking primarily at the row level for optimal concurrency, with locks acquired automatically during data manipulation language (DML) operations like SELECT, INSERT, UPDATE, and DELETE. Implicit locking occurs without explicit user commands, as the database engine applies shared locks for reads and exclusive locks for writes to maintain isolation. In contrast, explicit locking allows developers to issue commands like Oracle's LOCK TABLE or PostgreSQL's LOCK TABLE to acquire locks on entire tables or rows via SELECT FOR UPDATE, providing finer control for application-specific needs. These mechanisms trace their roots to the locking schemes developed in IBM's System R project in the 1970s, which influenced SQL standards and commercial RDBMS designs. Locking integrates closely with transaction isolation levels defined in the SQL standard, where the choice of level determines the type and duration of locks applied. For instance, the READ COMMITTED isolation level—the default in , SQL Server, and —uses shared locks on rows during reads to prevent dirty reads (accessing uncommitted changes) while releasing them at the end of each statement, allowing higher concurrency than stricter levels like SERIALIZABLE. In REPEATABLE READ, shared locks persist for the transaction duration to ensure consistent reads, reducing anomalies like non-repeatable reads but potentially increasing lock contention. Granularity choices, such as row-level versus table-level, are often configurable in these systems to balance concurrency and overhead. A key modern feature in RDBMS is lock escalation, where the system converts multiple fine-grained row locks into coarser table locks to mitigate memory pressure from excessive lock structures. In SQL Server, escalation triggers when the number of locks exceeds a threshold (typically 5,000 per object or 40% of available lock memory), reducing overhead in high-concurrency scenarios. As of 2025, SQL Server's Optimized Locking feature reduces lock memory consumption and the number of locks by releasing them immediately after updating each row, helping to avoid escalation and improve concurrency for write-heavy workloads. Oracle maintains row-level locking without escalating row locks to block or table level under normal circumstances, relying instead on efficient in-memory management to handle large transaction volumes. PostgreSQL similarly avoids escalation, using multi-version concurrency control (MVCC) alongside locks to minimize contention, though advisory locks can be applied explicitly for custom granularity. Specific implementations highlight these principles. supports row-level exclusive locks through SELECT FOR UPDATE, with the NOWAIT option to fail immediately if the lock cannot be acquired, enabling non-blocking application logic. MySQL's storage engine provides multiple granularity locking, allowing row locks to coexist with table locks via intention locks, which signal higher-level intentions without blocking unrelated operations. In distributed environments, Google's Spanner extends record locking across global replicas using a with TrueTime APIs to ensure linearizable consistency, coordinating locks via for synchronous replication.

Deadlock Prevention and Resolution

A deadlock in database systems occurs when two or more transactions are unable to proceed because each holds a lock on a resource required by another, forming a circular wait condition. For instance, Transaction A acquires an exclusive lock on Record 1 and requests a lock on Record 2, while Transaction B acquires an exclusive lock on Record 2 and requests a lock on Record 1, resulting in both transactions blocking indefinitely. To prevent deadlocks, several techniques are employed during lock acquisition. One common method is lock ordering, where transactions acquire locks on in a predefined, consistent sequence based on a , such as record ID, ensuring no circular dependencies form. Another approach is implementing timeouts, where a transaction waiting for a lock aborts after a specified period to break potential cycles, though this may lead to unnecessary rollbacks. Conservative two-phase locking (C2PL), a variant of the seminal protocol, requires transactions to predeclare and acquire all necessary locks before executing any operations, preventing deadlocks by avoiding interleaved lock requests but at the cost of reduced concurrency. For systems that allow deadlocks to occur, detection and resolution mechanisms are critical. Database management systems (DBMS) typically maintain a , a where nodes represent transactions and edges indicate one transaction waiting for a lock held by another; cycles in this graph signal a deadlock. Upon detection, the DBMS selects a victim transaction for using criteria such as transaction age, number of locks held, or estimated cost to minimize overall impact. The selected transaction is aborted, its locks released, and it may be restarted, allowing other transactions to proceed. An example of deadlock diagnosis is provided in SQL Server, where the deadlock monitor generates an XML-formatted deadlock graph output detailing involved transactions, resources, and wait points for and tuning. Performance studies indicate that prevention techniques generally outperform detection and resolution approaches, as the latter incur overhead from graph maintenance and costly rollbacks under high contention workloads.

Advantages and Limitations

Benefits for Data Integrity

Record locking plays a crucial role in ensuring transaction isolation within database systems, thereby preventing concurrency anomalies that could compromise . Specifically, it mitigates dirty reads, where a transaction accesses uncommitted modifications from another transaction; non-repeatable reads, in which the same query executed twice within a transaction returns differing results due to concurrent updates; and phantom reads, where subsequent queries reveal new or vanished rows inserted or deleted by other transactions. These protections are achieved through isolation levels such as Read Committed, Repeatable Read, and Serializable, which rely on locking to enforce consistent views of data during concurrent access. By upholding the Isolation property of (Atomicity, Consistency, Isolation, Durability) compliance, record locking safeguards data consistency amid multi-user write operations, ensuring that transactions do not interfere in ways that violate predefined integrity constraints like primary keys or relationships. This mechanism allows databases to transition from one valid state to another without partial updates corrupting the overall dataset, even in environments with overlapping transactions. In practical applications, such as platforms, record locking prevents of inventory by atomically reserving stock during checkout processes, ensuring that concurrent purchase attempts do not exceed available quantities. Shared locks further enable safe parallelism by permitting multiple transactions to read the same records simultaneously while exclusive locks protect critical write operations, balancing concurrency with reliability in read-heavy workloads. Empirical evaluations of concurrency control protocols confirm that lock-based approaches substantially reduce data inconsistency errors in high-contention workloads, maintaining zero anomaly rates where optimistic methods may incur higher abort frequencies. For instance, in distributed systems under elevated update rates, protocols demonstrate robust integrity preservation compared to alternatives, with performance gains in correctness metrics during hotspot contention.

Drawbacks and Alternatives

Record locking, while effective for maintaining data consistency, introduces significant overhead in terms of CPU cycles and memory usage, as the database must allocate resources to manage lock structures, acquire, hold, and release locks for each affected record. This overhead escalates with fine-grained locking, where numerous individual locks per row increase the complexity of the lock manager, potentially leading to higher latency even in low-contention environments. In high-contention scenarios, such as multiple transactions competing for the same records, record locking can drastically reduce system throughput by causing transactions to block and wait, thereby serializing access and limiting concurrent execution. This blocking effect is particularly pronounced during peak loads, where wait times accumulate, degrading overall performance and increasing response times for users. Scalability poses another challenge in distributed systems, where coordinating locks across multiple nodes introduces network latency and single points of contention, making it difficult to achieve linear performance gains as the system grows. Traditional two-phase locking protocols, commonly used with record locks, exacerbate this by requiring global synchronization, which hinders horizontal scaling in large clusters. The pessimistic nature of record locking assumes conflicts are likely, prompting early acquisition of locks that can lead to unnecessary waits and reduced concurrency, in contrast to optimistic approaches that permit parallel execution until a validation phase. This conservative , while preventing lost updates, often results in lower throughput when conflicts are infrequent, as transactions are preemptively stalled rather than proceeding and checking for issues later. An alternative to record locking is optimistic concurrency control, which avoids locks altogether by allowing transactions to read and modify data freely, then validating changes via version checks—such as comparing a row's version number before and after the transaction—to detect and resolve conflicts at commit time. This method suits environments with low conflict rates, as it minimizes blocking and supports higher concurrency without the overhead of lock management. Multiversion concurrency control (MVCC) offers another non-locking alternative, maintaining multiple versions of each record to enable snapshot isolation, where readers access a consistent view of the database without acquiring read locks, thus avoiding blocks on writers. In , MVCC implements this by assigning transaction IDs and using visibility rules to present snapshots, allowing concurrent reads and writes without interference while periodically cleaning up old versions to manage storage. This approach excels in read-heavy workloads, providing serializable isolation without the contention of traditional locks. Hybrid approaches combine record locking with MVCC to balance consistency and performance; for instance, employs MVCC for read operations to enable non-blocking queries while using locks for writes in high-conflict scenarios, reducing overall contention through selective locking. Record locking is preferable for write-heavy applications requiring low-latency guarantees and strict conflict prevention, whereas optimistic control or MVCC is better suited for read-heavy, scalable systems where minimizing overhead and maximizing throughput are priorities. In practice, the choice depends on contention levels: locking for environments with frequent updates, and alternatives for those emphasizing parallel access and reduced blocking.

References

  1. https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide?view=sql-server-ver17
  2. https://docs.oracle.com/cd/E24705_01/doc.91/e24234/record_locking.htm
  3. https://www.ibm.com/docs/en/rational-clearquest/10.0.6?topic=schemas-record-locking
  4. https://docs.progress.com/bundle/openedge-abl-basic-guided-journey/page/Record-locks.html
  5. https://www.ibm.com/docs/en/db2-for-zos/12.0.0?topic=concurrency-controls-locking
  6. https://docs.oracle.com/en/database/oracle/oracle-database/19/cncpt/data-concurrency-and-consistency.html
  7. https://books.google.com/books/about/Transaction_Processing.html?id=VFKbCgAAQBAJ
  8. https://www.oreilly.com/library/view/transaction-processing/9780080519555/xhtml/B9780080519555500126B.xhtml
  9. https://docs.oracle.com/cd/E17984_01/doc.898/e14700/record_locking.htm
  10. https://www.ibm.com/docs/en/ims/15.4.0?topic=databases-locking-protocols
  11. https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf
  12. https://jimgray.azurewebsites.net/papers/thetransactionconcept.pdf
  13. https://sigmodrecord.org/?smd_process_download=1&download_id=4373
  14. https://dl.acm.org/doi/10.1145/568271.223785
  15. https://www.oracle.com/us/corporate/profit/p27anniv-timeline-151918.pdf
  16. https://www.postgresql.org/docs/current/explicit-locking.html
  17. https://dl.acm.org/doi/10.1145/1282480.1282513
  18. https://pages.cs.wisc.edu/~nil/764/Trans/13_P428.pdf
  19. https://dev.mysql.com/doc/refman/8.4/en/internal-locking.html
  20. https://docs.oracle.com/en/database/other-databases/timesten/22.1/operations/concurrency-control-isolation-and-locking.html
  21. https://docs.oracle.com/en/database/oracle/oracle-database/23/sqlrf/LOCK-TABLE.html
  22. https://www.postgresql.org/docs/current/sql-lock.html
  23. https://www.cs.cmu.edu/~natassa/courses/15-721/papers/p632-chamberlin.pdf
  24. https://learn.microsoft.com/en-us/sql/t-sql/statements/set-transaction-isolation-level-transact-sql?view=sql-server-ver17
  25. https://www.postgresql.org/docs/current/transaction-iso.html
  26. https://dev.mysql.com/doc/refman/en/innodb-transaction-isolation-levels.html
  27. https://learn.microsoft.com/en-us/sql/relational-databases/performance/optimized-locking?view=sql-server-ver17
  28. https://dev.mysql.com/doc/refman/8.2/en/innodb-locking.html
  29. https://research.google.com/archive/spanner-osdi2012.pdf
  30. https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-deadlocks-guide?view=sql-server-ver17
  31. https://www.ibm.com/docs/en/order-management?topic=database-coding-guidelines-avoid-deadlocks
  32. https://dsf.berkeley.edu/dbcourse/lecs/23ccmore.pdf
  33. https://www.cs.purdue.edu/homes/clifton/cs542/protected/2PL.pdf
  34. https://research.cs.wisc.edu/techreports/1985/TR590.pdf
  35. https://www.sqlshack.com/sql-server-selects-deadlock-victim/
  36. https://learn.microsoft.com/en-us/sql/odbc/reference/develop-app/transaction-isolation-levels?view=sql-server-ver17
  37. https://www.bmc.com/blogs/acid-atomic-consistent-isolated-durable/
  38. https://www.ibm.com/docs/en/db2/11.1.0?topic=issues-isolation-levels
  39. https://help.shopline.com/hc/en-001/articles/20024302623129-Locking-Inventory-During-Checkout-to-Prevent-Overselling
  40. https://www.geeksforgeeks.org/dbms/lock-based-concurrency-control-protocol-in-dbms/
  41. https://db.cs.cmu.edu/papers/2017/p553-harding.pdf
  42. https://arxiv.org/pdf/2504.06854
  43. https://aditya-sunjava.medium.com/database-locking-explained-ensuring-integrity-while-impacting-performance-in-concurrent-systems-5206de0cff9e
  44. https://dev.to/sten/understanding-row-level-locking-in-databases-2c8j
  45. https://www.cs.umd.edu/~abadi/papers/vll-vldb13.pdf
  46. https://www.cockroachlabs.com/blog/what-is-database-contention/
  47. https://www.dbta.com/Editorial/Think-About-It/Minimizing-Database-Lock-Contention-Issues-140770.aspx
  48. https://www.architecture-weekly.com/p/distributed-locking-a-practical-guide
  49. https://www.dremio.com/wiki/distributed-locking/
  50. https://www2.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-168.pdf
  51. https://www.geeksforgeeks.org/dbms/difference-between-pessimistic-approach-and-optimistic-approach-in-dbms/
  52. https://stackoverflow.com/questions/129329/optimistic-vs-pessimistic-locking
  53. https://medium.com/%40sumit-s/optimistic-locking-concurrency-control-with-a-version-column-2e3db2a8120d
  54. https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/database-transactions-optimistic-concurrency
  55. https://leapcell.io/blog/diving-deep-into-mvcc-in-postgresql
  56. https://stackoverflow.com/questions/27499/what-is-multiversion-concurrency-control-mvcc-and-who-supports-it
  57. https://faculty.cc.gatech.edu/~jarulraj/courses/8803-s21/slides/16-multi-version-concurrency-control.pdf
  58. https://www.freecodecamp.org/news/how-databases-guarantee-isolation/
  59. https://blog.stackademic.com/understanding-concurrency-control-2pl-vs-mvcc-in-database-systems-2e8af23f1668
  60. https://blogs.oracle.com/maa/from-chaos-to-order-the-importance-of-concurrency-control-within-the-database-2-of-6
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.