顯式樂(lè)觀鎖定

在上一篇文章中 ，我介紹了Java持久性鎖定的基本概念。

隱式鎖定機(jī)制可防止丟失更新 ，它適用于我們可以主動(dòng)修改的實(shí)體。 雖然隱式樂(lè)觀鎖定是一種廣泛使用的技術(shù)，但是很少有人了解顯式樂(lè)觀鎖定模式的內(nèi)部工作原理。

當(dāng)鎖定的實(shí)體始終由某些外部機(jī)制修改時(shí)，顯式樂(lè)觀鎖定可以防止數(shù)據(jù)完整性異常。

產(chǎn)品訂購(gòu)用例

假設(shè)我們有以下域模型：

我們的用戶愛(ài)麗絲想訂購(gòu)產(chǎn)品。 購(gòu)買過(guò)程分為以下步驟：

• 愛(ài)麗絲加載產(chǎn)品實(shí)體
• 因?yàn)閮r(jià)格方便，她決定訂購(gòu)產(chǎn)品
• 價(jià)格引擎批處理作業(yè)更改了產(chǎn)品價(jià)格（考慮了貨幣更改，稅項(xiàng)更改和市場(chǎng)營(yíng)銷活動(dòng)）
• 愛(ài)麗絲發(fā)出訂單而沒(méi)有注意到價(jià)格變動(dòng)

隱式鎖定的缺點(diǎn)

首先，我們將測(cè)試隱式鎖定機(jī)制是否可以防止此類異常。 我們的測(cè)試用例如下所示：

doInTransaction(new TransactionCallable<Void>() {@Overridepublic Void execute(Session session) {final Product product = (Product) session.get(Product.class, 1L);try {executeAndWait(new Callable<Void>() {@Overridepublic Void call() throws Exception {return doInTransaction(new TransactionCallable<Void>() {@Overridepublic Void execute(Session _session) {Product _product = (Product) _session.get(Product.class, 1L);assertNotSame(product, _product);_product.setPrice(BigDecimal.valueOf(14.49));return null;}});}});} catch (Exception e) {fail(e.getMessage());}OrderLine orderLine = new OrderLine(product);session.persist(orderLine);return null;} });

測(cè)試生成以下輸出：

#Alice selects a Product Query:{[select abstractlo0_.id as id1_1_0_, abstractlo0_.description as descript2_1_0_, abstractlo0_.price as price3_1_0_, abstractlo0_.version as version4_1_0_ from product abstractlo0_ where abstractlo0_.id=?][1]} #The price engine selects the Product as well Query:{[select abstractlo0_.id as id1_1_0_, abstractlo0_.description as descript2_1_0_, abstractlo0_.price as price3_1_0_, abstractlo0_.version as version4_1_0_ from product abstractlo0_ where abstractlo0_.id=?][1]} #The price engine changes the Product price Query:{[update product set description=?, price=?, version=? where id=? and version=?][USB Flash Drive,14.49,1,1,0]} #The price engine transaction is committed DEBUG [pool-2-thread-1]: o.h.e.t.i.j.JdbcTransaction - committed JDBC Connection#Alice inserts an OrderLine without realizing the Product price change Query:{[insert into order_line (id, product_id, unitPrice, version) values (default, ?, ?, ?)][1,12.99,0]} #Alice transaction is committed unaware of the Product state change DEBUG [main]: o.h.e.t.i.j.JdbcTransaction - committed JDBC Connection

隱式樂(lè)觀鎖定機(jī)制無(wú)法檢測(cè)到外部更改，除非實(shí)體也被當(dāng)前的持久性上下文更改。 為了防止發(fā)出過(guò)時(shí)的Product狀態(tài)訂單，我們需要在Product實(shí)體上應(yīng)用顯式鎖定。

明確鎖定救援

Java Persistence LockModeType.OPTIMISTIC是此類情況的合適候選者，因此我們將對(duì)其進(jìn)行測(cè)試。

Hibernate帶有LockModeConverter實(shí)用程序，該實(shí)用程序能夠?qū)⑷魏蜫ava Persistence LockModeType映射到與其關(guān)聯(lián)的Hibernate LockMode 。

為了簡(jiǎn)單起見(jiàn)，我們將使用特定于Hibernate的LockMode.OPTIMISTIC ，該方法實(shí)際上與其Java持久性對(duì)應(yīng)項(xiàng)相同。

根據(jù)Hibernate文檔，顯式的OPTIMISTIC鎖定模式將：

假設(shè)交易不會(huì)對(duì)實(shí)體產(chǎn)生競(jìng)爭(zhēng)。 實(shí)體版本將在交易結(jié)束時(shí)進(jìn)行驗(yàn)證。

我將調(diào)整測(cè)試用例，改為使用顯式OPTIMISTIC鎖定：

try {doInTransaction(new TransactionCallable<Void>() {@Overridepublic Void execute(Session session) {final Product product = (Product) session.get(Product.class, 1L, new LockOptions(LockMode.OPTIMISTIC));executeAndWait(new Callable<Void>() {@Overridepublic Void call() throws Exception {return doInTransaction(new TransactionCallable<Void>() {@Overridepublic Void execute(Session _session) {Product _product = (Product) _session.get(Product.class, 1L);assertNotSame(product, _product);_product.setPrice(BigDecimal.valueOf(14.49));return null;}});}});OrderLine orderLine = new OrderLine(product);session.persist(orderLine);return null;}});fail("It should have thrown OptimisticEntityLockException!"); } catch (OptimisticEntityLockException expected) {LOGGER.info("Failure: ", expected); }

新的測(cè)試版本將生成以下輸出：

#Alice selects a Product Query:{[select abstractlo0_.id as id1_1_0_, abstractlo0_.description as descript2_1_0_, abstractlo0_.price as price3_1_0_, abstractlo0_.version as version4_1_0_ from product abstractlo0_ where abstractlo0_.id=?][1]} #The price engine selects the Product as well Query:{[select abstractlo0_.id as id1_1_0_, abstractlo0_.description as descript2_1_0_, abstractlo0_.price as price3_1_0_, abstractlo0_.version as version4_1_0_ from product abstractlo0_ where abstractlo0_.id=?][1]} #The price engine changes the Product price Query:{[update product set description=?, price=?, version=? where id=? and version=?][USB Flash Drive,14.49,1,1,0]} #The price engine transaction is committed DEBUG [pool-1-thread-1]: o.h.e.t.i.j.JdbcTransaction - committed JDBC Connection#Alice inserts an OrderLine Query:{[insert into order_line (id, product_id, unitPrice, version) values (default, ?, ?, ?)][1,12.99,0]} #Alice transaction verifies the Product version Query:{[select version from product where id =?][1]} #Alice transaction is rolled back due to Product version mismatch INFO [main]: c.v.h.m.l.c.LockModeOptimisticTest - Failure: org.hibernate.OptimisticLockException: Newer version [1] of entity [[com.vladmihalcea.hibernate.masterclass.laboratory.concurrency. AbstractLockModeOptimisticTest$Product#1]] found in database

操作流程如下：

在交易結(jié)束時(shí)檢查產(chǎn)品版本。 任何版本不匹配都會(huì)觸發(fā)異常和事務(wù)回滾。

比賽條件風(fēng)險(xiǎn)

不幸的是，應(yīng)用程序級(jí)別的版本檢查和事務(wù)提交不是原子操作。 該檢查發(fā)生在EntityVerifyVersionProcess中 ，在交易之前提交階段：

public class EntityVerifyVersionProcess implements BeforeTransactionCompletionProcess {private final Object object;private final EntityEntry entry;/*** Constructs an EntityVerifyVersionProcess** @param object The entity instance* @param entry The entity's referenced EntityEntry*/public EntityVerifyVersionProcess(Object object, EntityEntry entry) {this.object = object;this.entry = entry;}@Overridepublic void doBeforeTransactionCompletion(SessionImplementor session) {final EntityPersister persister = entry.getPersister();final Object latestVersion = persister.getCurrentVersion( entry.getId(), session );if ( !entry.getVersion().equals( latestVersion ) ) {throw new OptimisticLockException(object,"Newer version [" + latestVersion +"] of entity [" + MessageHelper.infoString( entry.getEntityName(), entry.getId() ) +"] found in database");}} }

調(diào)用AbstractTransactionImpl.commit（）方法，將執(zhí)行before-transaction-commit階段，然后提交實(shí)際的事務(wù)：

@Override public void commit() throws HibernateException {if ( localStatus != LocalStatus.ACTIVE ) {throw new TransactionException( "Transaction not successfully started" );}LOG.debug( "committing" );beforeTransactionCommit();try {doCommit();localStatus = LocalStatus.COMMITTED;afterTransactionCompletion( Status.STATUS_COMMITTED );}catch (Exception e) {localStatus = LocalStatus.FAILED_COMMIT;afterTransactionCompletion( Status.STATUS_UNKNOWN );throw new TransactionException( "commit failed", e );}finally {invalidate();afterAfterCompletion();} }

在支票和實(shí)際交易提交之間，其他交易在很短的時(shí)間內(nèi)默默地提交產(chǎn)品價(jià)格變化。

結(jié)論

顯式的OPTIMISTIC鎖定策略為過(guò)時(shí)的狀態(tài)異常提供了有限的保護(hù)。 此競(jìng)爭(zhēng)條件是“檢查時(shí)間”到“使用時(shí)間數(shù)據(jù)完整性異常”的典型情況。

在下一篇文章中，我將解釋如何使用explicit lock upgrade技術(shù)保存該示例。

• 代碼可在GitHub上獲得 。

翻譯自: https://www.javacodegeeks.com/2015/01/hibernate-locking-patterns-how-does-optimistic-lock-mode-work.html

總結(jié)

以上是生活随笔為你收集整理的休眠锁定模式–乐观锁定模式如何工作的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。