Roo中的@Version

问题提出

当我们为entity添加@RooJpaActiveRecord注解时，Roo为我们自动生成了一个名为Entity_Roo_Jpa_Entity.aj的文件，其中有一句：

@Version@Column(name ="version")privateIntegerEntity.version;

这是什么意思呢？“Version”是版本的意思，那么“@Version”注解是版本号的意思吗？Entity为什么需要版本管理？下面我们对此展开探寻。

线索

注意到Entity_Roo_Jpa_Entity.aj与@RooJpaActiveRecord有关，由上一篇博客可推测，@Version与JPA有关。打开Entity_Roo_Jpa_Entity.aj文件，鼠标移到@Version注解上，显示：

Specifies the version field or property of an entity class that serves as its optimistic lock value. The version is used to ensure integrity when performing the merge operation and for optimistic concurrency control.

可知，@Version的作用是声明注释的属性或者返回值作为optimistic lock value。version属性的作用是optimistic concurrency control。

Lock

optimistic lock的一般译为“乐观锁”，属于数据库事务并发控制领域的概念。数据库并发控制一般由“Lock（锁）”来实现的。这里提到：

Transactional isolation is usually implemented by locking whatever is accessed in a transaction. There are two different approaches to transactional locking: Pessimistic locking and optimistic locking.

可知transaction的isolation性质（ACID中的I）通常通过lock进行访问控制来实现。lock具体可分为pessimistic lock（悲观锁）和optimistic lock（乐观锁）。

pessimistic lock（悲观锁）

pessimistic lock的意思是：

a resource is locked from the time it is first accessed in a transaction until the transaction is finished, making it inaccessible to other transactions during that time.

也就是说，在一个transaction中，data会被完全锁住，直到transaction结束。另一个transaction若要访问该data，则需要等待。注意pessimistic lock可能会引起循环等待导致死锁。由于pessimistic lock的特性，采取该并法策略可能会导致运行效率大幅度下降，故并不适合高并发、长事务的场景。

optimistic lock（乐观锁）

这里提到：

Optimistic locking does not use exclusive locks when reading. Instead, a check is made during the update to make sure that the record has not been changed since it was read.

这里也提到：

At commit time, when the resource is about to be updated in persistent storage, the state of the resource is read from storage again and compared to the state that was saved when the resource was first accessed in the transaction. If the two states differ, a conflicting update was made, and the transaction will be rolled back.

可以看出optimistic lock的实现原理是通过在准备同步数据库时（commit时）对比数据在transaction中初次读取时和当前在数据库中的状态，看其是否满足某种规则来决定此次同步是否成功，若不成功则rollback。

具体的实现，这里举了一个例子：

一般的应用是采用数据版本的方式（version）实现，在读取数据的时候将version读取出来，在保存数据的时候判断version 的值是否小于数据库中的version的值，小于则不允许更新，否则可以更新。

值得注意的是，optimistic lock的实现并不依赖于数据库，而是基于系统中的数据存储逻辑。故系统外部的更新并不受optimistic lock的控制，可能会造成脏数据被更新到系统当中。

@Version

那么，@Version注解的具体用法是怎么样的呢？结合API文档，如上所述，我们只需要在某个数值属性或者timestamp类型的属性上标注@Version注解即可：

@Version@Column(name ="version")privateIntegerEntity.version;

或者：

@Version@Column(name="version")protectedint getVersion(){return version;}

要注意：

每个class只能有一个@Version标注的属性。
@Version标注的属性应该属于该class的primary table（主表）。
@Version标注的属性的类型包括：int, Integer, short, Short, long, Long, java.sql.Timestamp
程序不应该手动修改@Version标注的属性（交由框架自动处理）。

本条目发布于2013/06/09。属于ROO分类，被贴了 JPA、optimistic lock 标签。

文章导航

← Roo中的ActiveRecord以及EntityManagement Roo中的i18n →

发表评论

电子邮件地址不会被公开。必填项已用*标注

姓名 *

电子邮件 *

站点

您可以使用这些HTML标签和属性： <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Notify me of follow-up comments by email.

Notify me of new posts by email.

NOTICE: You should type some Chinese word (like “你好”) in your comment to pass the spam-check, thanks for your patience!