乐观并发控制方法探讨

需积分: 10 101 浏览量更新于2024-09-12 收藏 986KB PDF 举报

"《乐观并发控制方法》本文探讨了数据库系统中的一种非锁定（non-blocking）并发控制策略，特别是在处理大量并发交易时，传统的数据对象锁定机制不再适用。作者们提出了两种乐观并发控制（Optimistic Concurrency Control, OCC）方法，它们的核心思想是"希望"在大多数情况下，事务之间的冲突不会发生，从而依赖于事务回滚作为主要的控制手段。乐观并发控制方法的主要特点包括： 1. **信任度与期望失败处理**：乐观并发控制假设在大多数操作中，系统可以继续运行而不会遇到冲突。事务在执行过程中不会立即锁住资源，而是完成操作后再检查是否与其他事务的修改产生了冲突。如果发现冲突，才进行必要的调整或回滚。 2. **基于版本管理**：这些方法通常依赖于版本跟踪，每个数据对象都有一个当前版本，事务在访问前获取该版本。事务在更新对象时，只修改自己的副本，只有当提交时才发现可能存在的冲突，这时可能需要回滚到上一个版本或者与其他事务协调解决。 3. **适用场景**：乐观并发控制适合那些冲突概率较低的应用场景，例如读多写少的操作，因为在这种情况下，冲突的可能性相对较小，系统性能会优于频繁的锁争用。此外，它也适用于分布式系统，因为锁定全局数据可能带来网络延迟和复杂性。 4. **关键字与主题分类**：本文的关键字包括数据库、并发控制、事务处理。在数据库技术的分类中，这属于4.32（并发控制理论）和4.33（并发控制算法）。 1. **介绍**：文章开篇通过分析共享数据库系统的挑战，强调了如何在确保数据完整性的同时提供高效并发访问。引入事务的概念，即任何遵循数据约束序列的操作集合，以此为基础探讨乐观并发控制的实现方式和优势。《乐观并发控制方法》是一篇深入研究了数据库并发控制领域的一种创新策略，它旨在通过减少锁定操作来提高系统性能，特别适用于那些冲突较少的场景。理解并应用这些方法对于设计高效的分布式系统和现代数据库架构至关重要。"

Optimistic Methods for Concurrency Control

215

read

validation write

b time

Fig. 1. The three phases of a transaction.

It is also possible using this approach to avoid problems (3) and (4) above. Finally,

if the transaction pattern becomes query dominant (i.e., most transactions are

read-only), then the concurrency control overhead becomes almost totally negli-

gible (a partial solution to problem (1)).

The idea behind this optimistic approach is quite simple, and may be summa-

rized as follows.

(1) Since reading a value or a pointer from a node can never cause a loss of

integrity, reads are completely unrestricted (however, returning a result from

a query is considered to be equivalent to a write, and so is subject to validation

as discussed below).

(2) Writes are severely restricted. It is required that any transaction consist of

two or three phases: a read phase,

validation phase, and a possible write

phase (see Figure 1). During the read phase, all writes take place on local

copies of the nodes to be modified. Then, if it can be established during the

validation phase that the changes the transaction made will not cause a loss

of integrity, the local copies are made global in the write phase. In the case

of a query, it must be determined that the result the query would return is

actually correct. The step in which it is determined that the transaction will

not cause a loss of integrity (or that it will return the correct result) is called

validation.

If, in a locking approach, locking is only necessary in the worst case, then in an

optimistic approach validation will fail also only in the worst case. If validation

does fail, the transaction will be backed up and start over again as a new

transaction. Thus a transaction will have a write phase only if the preceding

validation succeeds.

In Section 2 we discuss in more detail the read and write phases of transactions.

In Section 3 a particularly strong form of validation is presented. The correctness

criteria used for validation are based on the notion of serial equivalence [4, 12,

141. In the next two sections concurrency controls that rely on the serial equiva-

lence criteria developed in Section 3 for validation are presented. The family of

concurrency controls in Section 4 have serial final validation steps, while the

concurrency controls of Section 5 have completely parallel validation, at however

higher total cost. In Section 6 we analyze the application of optimistic methods

to controlling concurrent insertions in B-trees. Section 7 contains a summary and

a discussion of future research.

ACM Transactions on Database Systems, Vol. 6, No. 2, June 1981.

剩余13页未读，继续阅读

Quantum_bit

粉丝: 2
资源: 39

乐观并发控制方法探讨

Entity.Framework.Core.Cookbook.2nd.Edition

Entity Framework Core Cookbook - Second Edition 2016

Entity Framework Core Cookbook(2nd) azw3

Hudi 0.12.0 搭建

The database operation was expected to affect 1 row(s), but actually affected 0 row(s); data may have been modified or deleted since entities were loaded. See http://go.microsoft.com/fwlink/?LinkId=527962 for information on understanding and handling optimistic concurrency exceptions.

ElasticSearch 如何记录每次数据变更

es数据频繁的更新_ES并发更新导致冲突的问题

数据库的封锁机制是什么的主要方法

在并发情况下,Elasticsearch 如果保证读写一致?

多节点部署一致性问题

最新资源