休眠CascadeType.LOCK陷阱

介绍

引入了Hibernate 显式锁定支持以及Cascade Types之后，就该分析CascadeType.LOCK行为了。

休眠锁定请求触发内部LockEvent 。关联的DefaultLockEventListener可以将锁定请求级联到锁定实体子级。

由于CascadeType.ALL也包括CascadeType.LOCK ，因此当锁定请求从父级实体传播到子级实体时，值得理解。

测试时间

我们将从以下实体模型开始：

Post是PostDetail一对一关联和Comment一对多关联的Parent实体，这些关联用CascadeType.ALL标记：

@OneToMany(cascade = CascadeType.ALL, mappedBy = "post", orphanRemoval = true)
private List<Comment> comments = new ArrayList<>();@OneToOne(cascade = CascadeType.ALL, mappedBy = "post", optional = false, fetch = FetchType.LAZY)
private PostDetails details;

所有即将到来的测试用例将使用以下实体模型图：

doInTransaction(session -> {Post post = new Post();post.setName("Hibernate Master Class");post.addDetails(new PostDetails());post.addComment(new Comment("Good post!"));post.addComment(new Comment("Nice post!"));session.persist(post);
});

锁定管理实体

将受管实体加载到当前正在运行的持久性上下文中，并将所有实体状态更改转换为DML语句。

当托管父实体被锁定时：

doInTransaction(session -> {Post post = (Post) session.createQuery("select p " +"from Post p " +"join fetch p.details " +"where " +"   p.id = :id").setParameter("id", 1L).uniqueResult();session.buildLockRequest(new LockOptions(LockMode.PESSIMISTIC_WRITE)).lock(post);
});

只有父实体被锁定，因此可以防止级联：

select id from Post where id = 1 for update

Hibernate定义了一个范围 LockOption ，该范围（根据JavaDocs）应允许将锁定请求传播到Child实体：

“范围”是JPA定义的术语。基本上，这是关联锁定的级联。

session.buildLockRequest(new LockOptions(LockMode.PESSIMISTIC_WRITE))
.setScope(true)
.lock(post);

设置范围标志不会改变任何东西，只有被管理实体被锁定：

select id from Post where id = 1 for update

锁定独立实体

除了实体锁定之外，锁定请求还可以重新关联分离的实体。为了证明这一点，我们将在锁定实体请求之前和之后检查Post实体图：

void containsPost(Session session, Post post, boolean expected) {assertEquals(expected, session.contains(post));assertEquals(expected, session.contains(post.getDetails()));for(Comment comment : post.getComments()) {assertEquals(expected, session.contains(comment));}
}

以下测试演示了CascadeType.LOCK如何用于分离的实体：

//Load the Post entity, which will become detached
Post post = doInTransaction(session -> (Post) session.createQuery("select p " +"from Post p " +"join fetch p.details " +"join fetch p.comments " +"where " +"   p.id = :id")
.setParameter("id", 1L)
.uniqueResult());//Change the detached entity state
post.setName("Hibernate Training");
doInTransaction(session -> {//The Post entity graph is detachedcontainsPost(session, post, false);//The Lock request associates //the entity graph and locks the requested entitysession.buildLockRequest(new LockOptions(LockMode.PESSIMISTIC_WRITE)).lock(post);//Hibernate doesn't know if the entity is dirtyassertEquals("Hibernate Training", post.getName());//The Post entity graph is attachedcontainsPost(session, post, true);
});
doInTransaction(session -> {//The detached Post entity changes have been lostPost _post = (Post) session.get(Post.class, 1L);assertEquals("Hibernate Master Class", _post.getName());
});

锁定请求重新关联了实体图，但是当前正在运行的Hibernate Session并未意识到处于分离状态的实体变脏了。仅在不强制执行UPDATE或选择当前数据库状态进行进一步比较的情况下，才重新连接实体。

一旦对实体进行管理，脏检查机制将检测到任何进一步的更改，并且刷新也会传播重新附加的更改。如果在管理实体时未发生任何更改，则不会安排该实体进行刷新。

如果要确保分离的实体状态始终与数据库同步，则需要使用merge或update 。

当scope选项设置为true时，分离的实体传播lock选项：

session.buildLockRequest(new LockOptions(LockMode.PESSIMISTIC_WRITE))
.setScope(true)
.lock(post);

Post实体锁定事件会传播到所有Child实体（因为我们正在使用CascadeType.ALL ）：

select id from Comment where id = 1 for update
select id from Comment where id = 2 for update
select id from PostDetails where id = 1 for update
select id from Post where id = 1 for update

结论

锁级联不是简单明了或直观的。显式锁定需要勤奋（我们获取的锁越多，死锁的机会就越大），并且无论如何，最好保留对Child实体锁传播的完全控制权。因此，与并发编程最佳实践类似，手动锁定优于自动锁定传播。

代码可在GitHub上获得。

翻译自: https://www.javacodegeeks.com/2015/03/hibernate-cascadetype-lock-gotchas.html