作用
通过冲突监测和事务回滚来防止并发业务事务中的冲突。一个业务事务的执行常常跨越一系列的系统事务。超出单个系统事务范围时,不能依靠数据库管理系统来确保业务事务中数据的一致性。乐观锁验证会话之间的修改冲突,悲观锁直接限制系统并发行。
运行机制
- 通过检查在会话读取一条记录后,没有其他会话修改该数据来保证数据的一致性。只要系统对数据库有修改,就需要获取乐观离线锁。
- 可以通过对每条记录关联一个版本号的方法跟踪修改。获取乐观离线锁的本质是比较会话中的数据版本号和当前记录数据的版本号。
- 通过在所有的更新和删除记录的SQL语句中加上对版本号的判别完成锁的检查。
- 还可以在Update语句的where子句中对所有字段进行检查。无需版本字段。
- 版本号不能防止不一致读。由于只在修改数据时检测冲突,所以很可能在某处读出不一致的信息,然后再去修改其他信息。
- 乐观离线锁也可以检测不一致读问题,一般地,对要读取的数据也加上版本号判别。
- 粗粒度锁可以通过对一组对象使用单个锁来解决某些不一致读的问题。
- 企业应用中的并发管理问题更是一个领域问题,而不只是技术问题。
- 源代码管理系统(SCM)检测到冲突时,可以自动合并修改并重新提交。
- 乐观离线锁如果提前通知冲突会更加有效。
使用时机
- 乐观离线锁适合业务视图冲突率低的情况。
- 乐观离线锁容易实现,因此在任何系统的业务事务冲突管理中优先考虑。
示例-领域层与数据映射器(Java)
确定领域对象结构:
Customer表 |
Id(primary key) |
Name |
Createdby |
Created |
Modifiedby |
modified |
version |
查找领域对象:
对删除操作的处理: