关于乐观锁（Hibernate）的基本问题
我刚开始使用“乐观锁定”机制 - 我正在使用 hibernate（在 Jboss 中）和容器管理事务（CMT）。 我想处理以下情况：在我的实体读取和实体更新之间，其他人更新数据库中的同一实体（即行）。 在这种情况下，我想抛出异常..
我已经用 @Version 注释了我的实体 - 就像
@Version
private Long version;
现在，我很困惑这是否足以进行版本管理或者我需要显式调用 EntityManager.lock() api 就像
{
.
.
final QueryDTO queryDTO = entityManager.find(QueryDTO.class, id);
entityManager.lock(queryDTO, LockModeType.READ);
queryDTO.setStatus(updatedStatus);
entityManager.persist(queryDTO);
}
提前致谢，
I am new to use "optimistic locking" mechanism - I am using hibernate (in Jboss) and Container Managed Transaction (CMT).
I want to handle the scenario when, between my entity-read and entity-update someone else updates the same entity (i.e. row) in DB.
In such case I want to throw exception..
I have annotated my entity with @Version - like
@Version
private Long version;
Now, I am confused if this is enough for version management or I need to explicitly call
the EntityManager.lock() api like
{
.
.
final QueryDTO queryDTO = entityManager.find(QueryDTO.class, id);
entityManager.lock(queryDTO, LockModeType.READ);
queryDTO.setStatus(updatedStatus);
entityManager.persist(queryDTO);
}
Thanks in advance,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
通过 @Version 使用乐观锁定时，根本不需要显式锁定（悲观锁定）。当实体更新到数据库时，将发生类似于以下查询的操作：
UPDATE QueryDTO SET status=, ...其他值..., version=100 WHERE id=; AND version=99 如果更新失败（某人/其他东西更改了数据和版本），您将得到 OptimisticLockException （因为您使用的是 EntityManager，我认为这是关于JPA，在“原始”Hibernate 中，它可能类似于 StaleStateException）。
You don't need explicit locks (pessimistic locking) at all when using optimistic locking via @Version. When the entity is being updated to database, something like the following query will take place:
UPDATE QueryDTO SET status=<updated status>, ...other values..., version=100 WHERE id=<id> AND version=99If the update fails (someone/something else has changed the data and version), you'll get
OptimisticLockException(Since you're using EntityManager, I assume this is about JPA, in "raw" Hibernate it could have been something like StaleStateException).