Does ordered sharing allow unrestricted conflicting access?

No. It imposes ordering and completion constraints through a complete protocol.

Can a transaction finish its calculations but still wait?

Yes. Commitment may depend on another transaction's termination.

Do all variants have identical recovery behavior?

No. Their treatment of conflicts and recovery differs.

AI Glossary / Data engineering and architecture / Advanced

Locks with ordered sharing

Definition

Locks with ordered sharing are database concurrency-control mechanisms that permit selected conflicting operations to proceed in a required order while retaining constraints on transaction completion. They extend the usual distinction between compatible and incompatible locks. The purpose is to increase useful concurrency without simply abandoning transaction correctness. The term refers to a family of protocol designs, not an instruction to let any reader and writer access data without coordination.

What it means

A transaction can finish one operation before it finishes all its work. Conventional conflict handling may keep another transaction waiting throughout that longer period. Ordered sharing asks whether some later work can proceed after the earlier operation, with the relationship between the transactions recorded and respected. This separates permission to perform an operation from permission to commit a complete transaction. For a business reader, the important distinction is between making progress and making a result final: the former can occur while the latter remains conditional.

How it works

In the ordered-sharing rule described by Agrawal and colleagues, the later related operation follows the earlier operation, and the later transaction cannot commit until the preceding transaction terminates. Protocol variants differ in which conflicts allow this relationship and how they handle recovery. Some retain particular blocking relationships; others use committed earlier versions. Consequently, avoiding an operation-level wait can introduce a completion dependency. Correctness requires the whole protocol, including abort handling, rather than an isolated compatibility-table change. The original research develops generalized locking mechanisms and evaluates them under stated workloads; it is not a universal performance guarantee.

Three practical examples

A database researcher compares a conventional locking schedule with a schedule that allows a later operation to execute while an earlier transaction is still active.
A time-sensitive processing experiment measures completed transactions and missed deadlines while also recording waits at commitment.
An engineering review examines whether a proposed concurrency change handles dependent transactions correctly when an earlier transaction aborts.

Think of it this way

Imagine two editors working on successive stages of a report. The second can begin an allowed stage after the first has completed the relevant work, even though the first editor still has other tasks. Final release remains subject to the agreed dependencies. This analogy separates progress from finality; it does not replace the database's rules for recovering from an abandoned or incorrect change.

Worked example

Consider an original simplified timing illustration. Transaction A performs the relevant earlier operation at time 1 and successfully commits at time 10. Transaction B's corresponding later operation takes place at time 2 under an allowed ordered-sharing relationship. B finishes its other work and requests commitment at time 6. Assume there are no other dependencies, aborts or scheduling costs. B cannot commit at time 6 because A has not terminated. It waits four time units, from 6 to 10, and can then commit after A under the stipulated conditions. The example demonstrates overlap followed by a commitment wait. It does not calculate a throughput improvement, and changing A's outcome to an abort would require applying the selected protocol's recovery rules rather than automatically approving B.

Illustrative case study

In a fictional database laboratory, a team evaluates a concurrency proposal for a reservation-processing prototype. An early dashboard counts operations that have executed and appears encouraging. A reviewer asks for transaction outcomes as well, since unfinished dependencies could make that count misleading. The team adds measures for committed transactions, completion waits, aborted work and deadline outcomes. It also introduces an earlier-transaction failure to test recovery behavior. This experiment exposes the difference between allowing more work to start and safely delivering more completed results. The scenario is an educational design exercise, not a claim that a particular commercial reservation system implements ordered sharing.

Common misconceptions and mistakes

Ordered sharing is not ordinary shared read locking under a different name. It also does not mean acquiring every lock in alphabetical order, although consistent resource-ordering techniques address other concurrency problems. Another mistake is assuming that removing some waits removes all waiting or all deadlocks. Dependencies still require management. The real-time research includes variants with different recovery properties, so readers should not transfer a property of one variant to every member of the family. Finally, a transaction reaching its last calculation is not necessarily entitled to commit immediately.

Business use

This concept is most useful when assessing database concurrency research or evaluating detailed claims about transaction-processing behavior. Ask what counts as successful work and whether the measurement includes eventual commitment. A higher count of executed operations can conceal waiting, rollback or repeated processing. Specify the workload, contention pattern and failure scenarios before comparing designs. For an AI-enabled application using a transactional store, the same operational questions apply to its supporting data system; the AI component does not remove database dependencies. Treat adoption as an implementation-specific engineering decision requiring correctness evidence and realistic testing.

Check your understanding

When did B request commitment in the toy example?

Answer: At time 6.

When did A successfully commit?

Answer: At time 10.

How long was B's illustrated completion wait?

Answer: Four time units.

Why could the laboratory not judge success from executed operations alone?

Answer: Those operations might belong to transactions that are still waiting or eventually abort.

Related terms

Two-phase locking
Concurrency control
serializability
transaction commitment
recoverability
cascading abort

Learn next

Draw a timeline for two transactions showing operation execution, completion requests and actual commitment. Add a dependency from the earlier transaction to the later one. Then consider an abort of the earlier transaction. Identify which questions require the exact recovery protocol before you can decide the later transaction's outcome.

Sources

Divyakant Agrawal and Amr El Abbadi, Ordered Sharing: A New Lock Primitive for Database Systems, publisher abstract: https://www.sciencedirect.com/science/article/pii/0306437995000205 Divyakant Agrawal, Amr El Abbadi, Richard Jeffers and Lijing Lin, Ordered Shared Locks for Real-Time Databases: https://www.vldb.org/journal/VLDBJ4/P087.pdf The timeline, editing analogy and laboratory case are original educational illustrations. The sources support the protocol family and operation-versus-commit distinction; the entry does not generalize a particular variant's recovery or simulated performance to all implementations.

Previous: Locking Next: Loess