青岛网站建设在哪,网页qq网址,站长必备网站,网站开发研究总结介绍 在我以前的文章中 #xff0c;我解释了OPTIMISTIC锁定模式是如何工作的#xff0c;以及它如何帮助我们同步外部实体状态更改。 在本文中#xff0c;我们将介绍OPTIMISTIC_FORCE_INCREMENT锁定模式的使用模式。 使用LockModeType.OPTIMISTIC #xff0c;将在当前正在运… 介绍 在我以前的文章中 我解释了OPTIMISTIC锁定模式是如何工作的以及它如何帮助我们同步外部实体状态更改。 在本文中我们将介绍OPTIMISTIC_FORCE_INCREMENT锁定模式的使用模式。 使用LockModeType.OPTIMISTIC 将在当前正在运行的事务结束时检查锁定的实体版本以确保我们不使用陈旧的实体状态。 由于应用程序级验证的性质 该策略易受竞争条件的影响因此需要附加的悲观锁 。 LockModeType.OPTIMISTIC_FORCE_INCREMENT不仅会检查预期的锁定实体版本还会对其进行递增。 检查和更新都发生在同一UPDATE语句中因此利用了当前数据库事务隔离级别和关联的物理锁定保证。 值得注意的是即使当前运行的事务未更改实体状态锁定的实体版本也会被提高。 集中版本控制用例 作为练习我们将模拟一个集中化的版本控制系统 其建模如下 存储库是我们的系统根实体每个状态更改都由Commit子实体表示。 每个Commit可能包含一个或多个Change组件这些组件作为单个原子工作单元传播。 存储库版本随着每个新的Commit而增加。 为简单起见我们只验证存储库实体版本尽管更现实的方法肯定会检查每个单独的文件版本以允许无冲突的提交并发进行。 测试时间 首先我们应该检查OPTIMISTIC_FORCE_INCREMENT锁定模式是否符合我们的用例要求 doInTransaction(new TransactionCallableVoid() {Overridepublic Void execute(Session session) {Repository repository (Repository) session.get(Repository.class, 1L);session.buildLockRequest(new LockOptions(LockMode.OPTIMISTIC_FORCE_INCREMENT)).lock(repository);Commit commit new Commit(repository);commit.getChanges().add(new Change(README.txt, 0a1,5...));commit.getChanges().add(new Change(web.xml, 17c17...));session.persist(commit);return null;}
}); 此代码生成以下输出 #Alice selects the Repository and locks it using an OPTIMISTIC_FORCE_INCREMENT Lock Mode
Query:{[select lockmodeop0_.id as id1_2_0_, lockmodeop0_.name as name2_2_0_, lockmodeop0_.version as version3_2_0_ from repository lockmodeop0_ where lockmodeop0_.id?][1]} #Alice makes two changes and inserts a new Commit
Query:{[select lockmodeop0_.id as id1_2_0_, lockmodeop0_.name as name2_2_0_, lockmodeop0_.version as version3_2_0_ from repository lockmodeop0_ where lockmodeop0_.id?][1]}
Query:{[insert into commit (id, repository_id) values (default, ?)][1]}
Query:{[insert into commit_change (commit_id, diff, path) values (?, ?, ?)][1,0a1,5...,README.txt]}
Query:{[insert into commit_change (commit_id, diff, path) values (?, ?, ?)][1,17c17...,web.xml]} #The Repository version is bumped up
Query:{[update repository set version? where id? and version?][1,1,0]} 我们的用户选择了一个存储库并发布了一个新的Commit 。 在交易结束时 存储库版本也会增加因此记录新的存储库状态更改。 冲突检测 在下一个示例中我们将有两个用户爱丽丝和鲍勃同时提交更改。 为避免丢失更新 两个用户都获得了显式的OPTIMISTIC_FORCE_INCREMENT锁定模式。 在Alice获得提交机会之前Bob刚刚完成了交易并增加了Repository版本。 Alice事务将回滚并引发不可恢复的 StaleObjectStateException 。 为了模拟冲突检测机制我们将使用以下测试方案 doInTransaction(new TransactionCallableVoid() {Overridepublic Void execute(Session session) {Repository repository (Repository) session.get(Repository.class, 1L);session.buildLockRequest(new LockOptions(LockMode.OPTIMISTIC_FORCE_INCREMENT)).lock(repository);executeAndWait(new CallableVoid() {Overridepublic Void call() throws Exception {return doInTransaction(new TransactionCallableVoid() {Overridepublic Void execute(Session _session) {Repository _repository (Repository) _session.get(Repository.class, 1L);_session.buildLockRequest(new LockOptions(LockMode.OPTIMISTIC_FORCE_INCREMENT)).lock(_repository);Commit _commit new Commit(_repository);_commit.getChanges().add(new Change(index.html, 0a1,2...));_session.persist(_commit);return null;}});}});Commit commit new Commit(repository);commit.getChanges().add(new Change(README.txt, 0a1,5...));commit.getChanges().add(new Change(web.xml, 17c17...));session.persist(commit);return null;}
}); 生成以下输出 #Alice selects the Repository and locks it using an OPTIMISTIC_FORCE_INCREMENT Lock Mode
Query:{[select lockmodeop0_.id as id1_2_0_, lockmodeop0_.name as name2_2_0_, lockmodeop0_.version as version3_2_0_ from repository lockmodeop0_ where lockmodeop0_.id?][1]} #Bob selects the Repository and locks it using an OPTIMISTIC_FORCE_INCREMENT Lock Mode
Query:{[select lockmodeop0_.id as id1_2_0_, lockmodeop0_.name as name2_2_0_, lockmodeop0_.version as version3_2_0_ from repository lockmodeop0_ where lockmodeop0_.id?][1]} #Bob makes a change and inserts a new Commit
Query:{[insert into commit (id, repository_id) values (default, ?)][1]}
Query:{[insert into commit_change (commit_id, diff, path) values (?, ?, ?)][1,0a1,2...,index.html]} #The Repository version is bumped up to version 1
Query:{[update repository set version? where id? and version?][1,1,0]} #Alice makes two changes and inserts a new Commit
Query:{[insert into commit (id, repository_id) values (default, ?)][1]}
Query:{[insert into commit_change (commit_id, diff, path) values (?, ?, ?)][2,0a1,5...,README.txt]}
Query:{[insert into commit_change (commit_id, diff, path) values (?, ?, ?)][2,17c17...,web.xml]} #The Repository version is bumped up to version 1 and a conflict is raised
Query:{[update repository set version? where id? and version?][1,1,0]}
INFO [main]: c.v.h.m.l.c.LockModeOptimisticForceIncrementTest - Failure:
org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect) :
[com.vladmihalcea.hibernate.masterclass.laboratory.concurrency.
LockModeOptimisticForceIncrementTest$Repository#1] 此示例表现出与典型的隐式乐观锁定机制相同的行为。 唯一的区别在于版本更改发起者。 虽然隐式锁定仅适用于修改实体但是显式锁定可以跨任何托管实体使用忽略实体状态更改要求。 结论 因此 OPTIMISTIC_FORCE_INCREMENT对于将子实体状态更改传播到未修改的父实体非常有用。 通过简单地锁定它们的公共父代此模式可以帮助我们同步各种实体类型。 当子实体状态更改必须触发父实体版本增加时您可能追求的是显式OPTIMISTIC_FORCE_INCREMENT锁定模式。 代码可在GitHub上获得 。 翻译自: https://www.javacodegeeks.com/2015/02/hibernate-locking-patterns-optimistic_force_increment-lock-mode-work.html
