事务的乐观锁和悲观锁

Select …forupdate语句是我们经常使用手工加锁语句。通常情况下，select语句是不会对数据加锁，妨碍影响其他的DML和DDL操作。同时，在多版本一致读机制的支持下，select语句也不会被其他类型语句所阻碍。

借助for update子句，我们可以在应用程序的层面手工实现数据加锁保护操作。本篇我们就来介绍一下这个子句的用法和功能。

从for update子句的语法状态图中，我们可以看出该子句分为两个部分：加锁范围子句和加锁行为子句。下面我们分别针对两个方面的进行介绍。

加锁范围子句

在select…for update之后，可以使用of子句选择对select的特定数据表进行加锁操作。默认情况下，不使用of子句表示在select所有的数据表中加锁。

//采用默认格式for update

SQL> select * from emp where rownum<2 for update;

此时，我们观察v$lock和v$locked_object视图，可以看到锁信息。

//事务信息视图

SQL> select addr,xidusn,xidslot,xidsqn from v$transaction;

//锁对象信息

SQL> select xidusn,xidslot,xidsqn,object_id,session_id, oracle_username from v$locked_object;

SQL> select owner,object_name from dba_objects where object_id=73181;

SQL> select addr, sid, type, id1,id2,lmode, request, block from v$lock where sid=36;

从上面的情况看，默认情况下的for update语句，效果相当于启动了一个会话级别的事务，在对应的数据表（select所涉及的所有数据表）上加入一个数据表级共享锁（TM，lmode=3）。同时，在对应的数据行中加入独占锁（TX，lmode=6）。

根据我们以前的知识，如果此时有另一个会话视图获取对应数据行的独占权限（无论是用update/delete还是另一个for update），都会以block而告终。

SQL> select sid from v$mystat where rownum<2;

SQL> select * from emp where empno=7369 for update;

//系统blocking

此时系统中状态，切换到另一个用户下进行观察：

SQL> select addr, sid, type, id1,id2,lmode, request, block from v$lock where sid in (36,37);

ADDR SID TYPE ID1 ID2 LMODE REQUEST BLOCK

SQL> select * from dba_waiters;

WAITING_SESSION HOLDING_SESSION LOCK_TYPE MODE_HELD MODE_REQUESTED LOCK_ID1 LOCK_ID2

由此，我们可以获取到结论：for update子句的默认行为就是自动启动一个事务，借助事务的锁机制将数据进行锁定。

Of子句是配合for update语句使用的一个范围说明标记。从官方的语法结构看，后面可以跟一个或者多个数据列列表。这种语法场景常常使用在进行连接查询的select中，对其中一张数据表数据进行锁定。

SQL> select empno,ename,job,mgr,sal from emp,dept where emp.deptno=dept.deptno and empno=7369 for update of emp.empno;

SQL> select addr, sid, type, id1,id2,lmode, request, block from v$lock where sid=36;

ADDR SID TYPE ID1 ID2 LMODE REQUEST BLOCK

上面的语句中，我们看到使用for update of指定数据列之后，锁定的范围限制在了所在的数据表。也就是说，当我们使用连接查询配合of子句的时候，可以实现有针对性的锁定。

同样在连接查询的时候，如果没有of子句，同样采用默认的模式，会如何呢？

SQL> select empno,ename,job,mgr,sal from emp,dept where emp.deptno=dept.deptno and empno=7369 for update;

SQL> select owner,object_name from dba_objects where object_id=73179;

明显可以看到，当我们没有使用of子句的时候，默认就是对所有select的数据表进行lock操作。

加锁行为子句

加锁行为子句相对比较容易理解。这里分别介绍。
Nowait子句

当我们进行for update的操作时，与普通select存在很大不同。一般select是不需要考虑数据是否被锁定，最多根据多版本一致读的特性读取之前的版本。加入for update之后，Oracle就要求启动一个新事务，尝试对数据进行加锁。如果当前已经被加锁，默认的行为必然是block等待。

使用nowait子句的作用就是避免进行等待，当发现请求加锁资源被锁定未释放的时候，直接报错返回。

///session1中

SQL> select * from emp for update;

//变换session，进行执行。

SQL> select * from emp for update nowait;

select * from emp for update nowait

ORA-00054:资源正忙,但指定以NOWAIT方式获取资源,或者超时失效

对应的还有就是wait子句，也就是默认的for update行为。一旦发现对应资源被锁定，就等待blocking，直到资源被释放或者用户强制终止命令。

对wait子句还存在一个数据参数位，表示当出现blocking等待的时候最多等待多长时间。单位是秒级别。

//接上面的案例

SQL> select * from emp for update wait 3;

select * from emp for update wait 3

ORA-30006:资源已被占用;执行操作时出现WAIT超时

Skip locked参数

Skip locked参数是最新引入到for update语句中的一个参数。简单的说，就是在对数据行进行加锁操作时，如果发现数据行被锁定，就跳过处理。这样for update就只针对未加锁的数据行进行处理加锁。

//session1中，对一部分数据加锁；

SQL> select * from emp where rownum<4 for update;

EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO

//在session2中；

SQL> select * from emp for update skip locked;

EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO

总数据一共14行。Session1中，先lock住了3行数据。之后的seesion2中，由于使用的skip locked子句参数，将剩下的11条数据进行读取到并且加锁。

对for update的使用

在日常中，我们对for update的使用还是比较普遍的，特别是在如pl/sql developer中手工修改数据。此时只是觉得方便，而对for update真正的含义缺乏理解。

For update是Oracle提供的手工提高锁级别和范围的特例语句。Oracle的锁机制是目前各类型数据库锁机制中比较优秀的。所以，Oracle认为一般不需要用户和应用直接进行锁的控制和提升。甚至认为死锁这类锁相关问题的出现场景，大都与手工提升锁有关。所以，Oracle并不推荐使用for update作为日常开发使用。而且，在平时开发和运维中，使用了for update却忘记提交，会引起很多锁表故障。

那么，什么时候需要使用for update？就是那些需要业务层面数据独占时，可以考虑使用for update。场景上，比如火车票订票，在屏幕上显示邮票，而真正进行出票时，需要重新确定一下这个数据没有被其他客户端修改。所以，在这个确认过程中，可以使用for update。这是统一的解决方案方案问题，需要前期有所准备

Hibernate中的乐观锁和悲观锁

在了解Hibernate的LockMode之前，我们先讲一下LockMode是什么东西？其实LockMode只是在使用Hibernate 中 的session.load()加载数据时指定的模式，也叫悲观锁（模式），然而，悲观锁是为了弥补read-committed 机制的不足，从而解决non-repeatable （不可重复读）和 phantom-read （幻读）问题，而non-repeatable 和 phantom-read 这两个问题也只是事务并发 是产生的两种问题…
看了我写的这一段后，我相信很多读者会有点懵，这就对了，看完下面的文章，再后过头来读这一段，就全都明白了。

我们知道，事务由那几个特性，四个（ACID）：

1.原子性(Atomicity）：
整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

2.一致性（Consistency）
在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。

3.隔离性（Isolation）
两个事务的执行是互不干扰的，一个事务不可能看到其他事务运行时，中间某一时刻的数据。

4.持久性（Durability）
　 在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

由于一项操作通常会包含许多子操作，而这些子操作可能会因为硬件的损坏或其他因素产生问题，要正确实现ACID并不容易。ACID建议数据库将所有需要更新以及修改的资料一次操作完毕，但实际上并不可行。

　　 一个支持事务（Transaction）的数据库系统，必需要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。

在处理事务过程中，事务并发是不可避免的，从而会出现以下几个问题：

1.丢失更新（Lost Update）（第一类和第二类）
2.脏读（Dirty Read）
3.不可重复读（Non-repeatable Read）
4.幻读（Phantom Read）

针对并发事务出现的问题，Hibernate 采用了数据库的事务隔离机制（详细文档见Herbernate 参考文档的 java.sql.Connection ）,一般有以下四种处理机制：

1.read-uncommitted
2.read-committed
3.repeatable read
4.serializable

四种机制的具体价值：

A. 只要数据库支持事务，就不可能出现第一类丢失更新
B. read-uncommitted（允许读取未提交的数据）会出现dirty read , phantom-read,non-repeatable read 问题
C. read-committed（读取已提交的数据，项目中一般使用这个，MySql 数据库默认是这种机制）不会出现dirty read ，因为只有另一个事务提交才会读出来结果，但仍然会出现non-repeatable和phantom-read

（所以使用read-committed 机制可用悲观锁和乐观锁来解决non-repeatable 和 phantom-read 问题）

在hibernate中的事务隔离级别的设定（使用 hibernate.connection.isolation配置，取之1，2，4，8）

1.hibernate.connection.isolation = 2 （如果不设置，默认依赖数据库本身的级别，例如MySql为2，read-committed）
2.使用悲观锁解决repeatable read 的问题(依赖于数据库的锁)

a. 使用悲观锁查找数据或者更新数据时，默认加上for update ，表示对当前事务加锁，其他事务暂时不能使用，例如select … for update
b. 在程序中如何加上悲观锁呢，很简单，直接在session的load方法中添加一个参数即可，例如：

Account a = (Account)session.load(Account.class, 1, LockMode.UPGRADE);

锁的模式：

a.LockMode.None 无锁的机制，Transaction介绍时，切换到此模式
b.LockMode.read 在查询的时候hibernate会自动获取锁
c.LockMode.write insert update hibernate会自动获取锁
d.以上3种锁的模式，是hibernate内部使用的（不需要设置）
e.LockMode.UPGRADE_NOWAIT 是Oracle 支持的索的模式

3.使用乐观锁解决repeatable read 的问题

直接在实体类中添加 version 属性(数据库也会对应生成该字段，初始值为0)，并在其get 方法前加 @version 注解（这里介绍注解方式配置），则在操作过程中每更新一次改行数据则在 version 值上加1，即可在事务提交前判断该数据是否被其他事务修改过

D. repeatable read (事务执行中其他事务无法执行修改或插入操作 较安全)
E. serializable 解决事务隔离级别（顺序执行事务，不并发，实际当中很少使用）

悲观锁

在应用程序中显示地为数据资源加锁.悲观锁假定当前事务操纵数据资源时,肯定还会有其它事务同时访问该数据资源,为了避免当前事务的操作受到干扰,先锁定资源.尽管悲观锁能防止丢失更新和不可重复读这类并发问题,但会影响并发性能.（简单理解，就是每次在操作数据时总是悲观地认为会有别的事务也会来操纵同一数据，从此锁住该笔数据，直到自己操作完成后再解除锁）

乐观锁

假定当前事务操纵数据资源时,不会有其它事务同时访问该数据资源,因此完全依靠数据库的隔离级别来自动管理锁的工作.应用程序采用版本控制手段来避免可能出现的并发问题.（所谓乐观锁，它通常认为多个事务同时操纵同一数据的情况是很少的，因为根本不做数据库层次上的锁定，只是基于数据的版本标识实现应用程序级别上的锁定机制，既保证了多个事务的并发访问，又有效地防止了第二类丢失更新的出现）

LockMode类表示的几种锁定模式

锁定模式

描述

LockMode.NONE

如果缓存中存在对象,直接返回该对象的引用,否则通过select语句到数据库中加载该对象,默认值.
LockMode.READ

不管缓存中是否存在对象,总是通过select语句到数据库中加载该对象,如果映射文件中设置了版本元素,就执行版本检查,比较缓存中的对象是否和数据库中对象版本一致

LockMode.UPGRADE

不管缓存中是否存在对象,总是通过select语句到数据库中加载该对象,如果映射文件中设置了版本元素,就执行版本检查,比较缓存中的对象是否和数据库中对象的版本一致,如果数据库系统支持悲观锁(如Oracle/MySQL),就执行select…for update语句,如果不支持(如Sybase),执行普通select语句

LockMode.UPGRADE_NOWAIT

和LockMode.UPGRADE具有同样功能,此外,对于Oracle等支持update nowait的数据库,执行select…for update nowait语句,nowait表明如果执行该select语句的事务不能立即获得悲观锁,那么不会等待其它事务释放锁,而是立刻抛出锁定异常

LockMode.WRITE

保存对象时会自动使用这种锁定模式,仅供Hibernate内部使用,应用程序中不应该使用它

LockMode.FORCE

强制更新数据库中对象的版本属性,从而表明当前事务已经更新了这个对象

多个事务并发运行时的并发问题

第一类丢失更新:撤销一个事务时,把其它事务已提交的更新数据覆盖.
第二类丢失更新:不可重复读中的特例,一个事务覆盖另一事务已提交的更新数据.
脏读:一个事务读到另一事务未提交的更新数据.
幻读:一个事务读到另一事务已提交的新插入的数据.
不可重复读:一个事务读到另一个事物已提交的更新数据.

锁的类型和兼容性

共享锁
l加锁条件:当一个事务执行select语句时,数据库系统会为这个事务分配一把共享锁,锁定被查询的数据.
l解锁条件:数据被读取后,数据库系统立即解除共享锁.
l与其它锁的兼容性:如果数据资源上放置了共享锁,还能再放置共享锁和更新锁.
l并发性能:良好的并发性能.当多个事务读相同数据时,每个事务都会获得一把共享锁,可以同时读锁定的数据.

独占锁
l加锁条件:当一个事务执行insert,update,delete时,数据库系统会自动对SQL语句操纵的数据资源使用独占锁.如果该数据资源已经有其它锁存在时,无法对其再放置独占锁.
l解锁条件:独占锁一直到事务结束后才能被解除.
l与其它锁的兼容性:独占锁不能和其他锁兼容,如果数据资源已经加上了独占锁, 就不能再放置其它锁,同样,如果已经有了其它锁,就不能放置独占锁.
l并发性能:并发性能较差,只允许有一个事务访问锁定的数据,如果其他事务也需要访问该数据,就必须等待,直到前一个事务结束,解除了独占锁,其它事务才能访问该数据.

更新锁
l加锁条件:当一个事务进行update操作时,数据库系统会先为事务分配一把更新锁.
l解锁条件:当读取数据完毕,执行更新操作时,会把更新锁升级为独占锁.
l与其它锁的兼容性:更新锁与共享锁兼容,即一个资源可以同时放置更新锁和共享锁,但是最多只能放置一把更新锁,这样,当多个事务更新相同的数据时,只有一个事务能获得更新锁,然后再把更新锁升级为独占锁,其它事务必须等到前一个事务结束后,才能获得更新锁,避免了死锁.
l并发性能:允许多个事务同时读锁定资源,但不允许其它事务修改它.

ReadUncommited读未提交数据

LockMode FORCE
Similiar to UPGRADE except that, for versioned entities, it results in a forced version increment.

LockMode NONE
No lock required.

LockMode READ
A shared lock. Objects in this lock mode were read from the database in the current transaction, rather than being pulled from a cache （注：也就是从数据库中读数据，绕过了Hibernate的Cache）

LockMode UPGRADE
An upgrade lock.（注：相当于SQL语句select xxx from xxxx for update，也就是把事务的处理交给了数据库）

LockMode UPGRADE_NOWAIT
Attempt to obtain an upgrade lock, using an Oracle-style select for update nowait.

LockMode WRITE
A WRITE lock is obtained when an object is updated or inserted.This lock mode is for internal use only and is not a valid mode for load() or lock() (both of which throw exceptions if WRITE is specified).（注：不能在load的时候用，否则抛出异常）

不过，“纸上得来终觉浅，觉知此事要躬行”，博主做了下实验来比较这些“锁”的不同。

先看代码：

package com.javaye;

import org.hibernate.LockMode;
import org.hibernate.Session;
import org.hibernate.Transaction;

import com.javaye.models.Article;

public class Main {

private static void insert(){
Session session = HibernateSessionFactory.getSession();
Transaction tx = session.beginTransaction();
Article art = new Article();
art.setTitle("AAA");
art.setVisitAmount(0);
session.saveOrUpdate(art);
tx.commit();
}

privatestatic void update(){
Session session = HibernateSessionFactory.getSession();
System.out.println("session:"+session.hashCode());
Transaction tx =session.beginTransaction();
Article art = (Article) session.load(Article.class, 1,LockMode.UPGRADE);
System.out.println("loaded");
art.setVisitAmount(art.getVisitAmount()+1);
session.save(art);
tx.commit();
session.evict(art);

}

private static void work(){
for(int i=0;i<10;i++){
System.out.println(Thread.currentThread().getName()+":"+(i+1)+"times.");
update();
}
}

public static void main(String[] args) throws Exception{
Thread t1 = new Thread(
new Runnable(){
public void run(){
work();
}
}
);

Thread t2 = new Thread(
new Runnable(){
public void run(){
work();
}
}
);
t1.setName("Thread1");
t2.setName("Thread2");
t1.setDaemon(true);
t2.setDaemon(true);
t1.start();
t2.start();
t1.join();
t2.join();
}
}

这是一个多线程程序，每个线程都会从数据库中取出visit_amount,然后加一，再存回数据库，每个线程重复10遍。

请注意蓝色的部分，我们在这里设一个断点，那么用Eclipse调试的时候，到达这个断点的线程就会停下来，由于它的事务还没有commit()，LockMode.UPGRADE的锁就还没有释放，那么另外一个线程中事务就会在load的时候因为不能获得锁而阻塞，那么理论上我们只会看到只有一句“loaded”输出。实验结果证明了我的猜想，LockMode.UPGRADE的情况下，如果一个事务获得了锁，即使另外的事务想读取数据也是不行的，必须等待锁的释放。

那么，改写数据可以吗？笔者又做了一个实验，打开MySQL Query Browser，直接生改数据库，把visit_amount字段的值硬生生改过来，结果发现提交的时候就阻塞了，MySQL的海豚标志一个劲的游泳，这说明，LockMode.UPGRADE级别的锁不是由Hibernate控制的，而是由数据库控制的。

再试一试LockeMode.Read，断点还是设在原来的位置，发现有两次“loaded”输出，证明两个事务可以同时读取这条数据，那么这个锁有什么作用呢？根据我实验的结果，似乎只是为了绕过cache，从数据库直接读取。为了证明我的猜想，我直接通过MySQL Query Browser更改了visit_amount，调试发现，Hibernate是从数据库中读取的新值，而不是cache中的老值。

最后在补充一点，LockMode.UPGRADE加锁是有超时时间的，如果加锁后超过一定的时间不commit，Hibernate会抛出异常。

为了得到最大的性能，一般数据库都有并发机制，不过带来的问题就是数据访问的冲突。为了解决这个问题，大多数数据库用的方法就是数据的锁定。

数据的锁定分为两种方法，第一种叫做悲观锁，第二种叫做乐观锁。什么叫悲观锁呢，悲观锁顾名思义，就是对数据的 搜索冲突采取一种悲观的态度，也就是说假设数据肯定会冲突，所以在数据开始读取的时候就把数据锁定住。而乐观锁就是认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让用户返回错误的信息，让用户决定如何去做。

先从悲观锁开始说。在SqlServer等其余很多数据库中，数据的锁定通常采用页级锁的方式，也就是说对一张表内的数据是一种串行化的更新插入机制，在任何时间同一张表只会插1条数据，别的想插入的数据要等到这一条数据插完以后才能依次插入。带来的后果就是性能的降低，在多用户并发访问的时候，当对一张表进行频繁操作时，会发现响应效率很低，数据库经常处于一种假死状态。而Oracle用的是行级锁，只是对想锁定的数据才进行锁定，其余的数据不相干，所以在对Oracle表中并发插数据的时候，基本上不会有任何影响。

注：对于悲观锁是针对并发的可能性比较大，而一般在我们的应用中用乐观锁足以。

Oracle的悲观锁需要利用一条现有的连接，分成两种方式，从SQL语句的区别来看，就是一种是for update，一种是for update nowait的形式。比如我们看一个例子。首先建立测试用的数据库表。

CREATE TABLE TEST(ID,NAME,LOCATION,VALUE,CONSTRAINT test_pk PRIMARY KEY(ID))AS SELECT deptno, dname, loc, 1 FROM scott.dept

这里我们利用了Oracle的Sample的scott用户的表，把数据copy到我们的test表中。首先我们看一下for update锁定方式。首先我们执行如下的select for update语句。

select * from test where id = 10 for update

通过这条检索语句锁定以后，再开另外一个sql*plus窗口进行操作，再把上面这条sql语句执行一便，你会发现sqlplus好像死在那里了，好像检索不到数据的样子，但是也不返回任何结果，就属于卡在那里的感觉。这个时候是什么原因呢，就是一开始的第一个Session中的select for update语句把数据锁定住了。由于这里锁定的机制是wait的状态(只要不表示nowait那就是wait)，所以第二个Session(也就是卡住的那个sql*plus)中当前这个检索就处于等待状态。当第一个session最后commit或者rollback之后，第二个session中的检索结果就是自动跳出来，并且也把数据锁定住。不过如果你第二个session中你的检索语句如下所示。

select * from test where id = 10

也就是没有for update这种锁定数据的语句的话，就不会造成阻塞了。另外一种情况，就是当数据库数据被锁定的时候，也就是执行刚才for update那条sql以后，我们在另外一个session中执行for update nowait后又是什么样呢。比如如下的sql语句。 由于这条语句中是制定采用nowait方式来进行检索，所以当发现数据被别的session锁定中的时候，就会迅速返回ORA-00054错误，内容是资源正忙, 但指定以 NOWAIT 方式获取资源。所以在程序中我们可以采用nowait方式迅速判断当前数据是否被锁定中，如果锁定中的话，就要采取相应的业务措施进行处理。

select * from test where id = 10 for update nowait

那这里另外一个问题，就是当我们锁定住数据的时候，我们对数据进行更新和删除的话会是什么样呢。比如同样，我们让第一个Session锁定住id=10的那条数据，我们在第二个session中执行如下语句。

update test set value=2 where id = 10

这个时候我们发现update语句就好像select for update语句一样也停住卡在这里，当你第一个session放开锁定以后update才能正常运行。当你update运行后，数据又被你update语句锁定住了，这个时候只要你update后还没有commit，别的session照样不能对数据进行锁定更新等等。

总之，Oracle中的悲观锁就是利用Oracle的Connection对数据进行锁定。在Oracle中，用这种行级锁带来的性能损失是很小的，只是要注意程序逻辑，不要给你一不小心搞成死锁了就好。而且由于数据的及时锁定，在数据提交时候就不呼出现冲突，可以省去很多恼人的数据冲突处理。缺点就是你必须要始终有一条数据库连接，就是说在整个锁定到最后放开锁的过程中，你的数据库联接要始终保持住。与悲观锁相对的，我们有了乐观锁。乐观锁一开始也说了，就是一开始假设不会造成数据冲突，在最后提交的时候再进行数据冲突检测。在乐观锁中，我们有3种

常用的做法来实现。

[1]第一种就是在数据取得的时候把整个数据都copy到应用中，在进行提交的时候比对当前数据库中的数据和开始的时候更新前取得的数据。当发现两个数据一模一样以后，就表示没有冲突可以提交，否则则是并发冲突，需要去用业务逻辑进行解决。

[2]第二种乐观锁的做法就是采用版本戳，这个在Hibernate中得到了使用。采用版本戳的话，首先需要在你有乐观锁的数据库table上建立一个新的column，比如为number型，当你数据每更新一次的时候，版本数就会往上增加1。比如同样有2个session同样对某条数据进行操作。两者都取到当前的数据的版本号为1，当第一个session进行数据更新后，在提交的时候查看到当前数据的版本还为1，和自己一开始取到的版本相同。就正式提交，然后把版本号增加1，这个时候当前数据的版本为2。当第二个session也更新了数据提交的时候，发现数据库中版本为2，和一开始这个session取到的版本号不一致，就知道别人更新过此条数据，这个

时候再进行业务处理，比如整个Transaction都Rollback等等操作。在用版本戳的时候，可以在应用程序侧使用版本戳的验证，也可以在数据库侧采用Trigger(触发器)来进行验证。不过数据库的Trigger的性能开销还是比较的大，所以能在应用侧进行验证的话还是推荐不用Trigger。

[3]第三种做法和第二种做法有点类似，就是也新增一个Table的Column，不过这次这个column是采用timestamp型，存储数据最后更新的时间。在Oracle9i以后可以采用新的数据类型，也就是timestamp with time zone类型来做时间戳。这种Timestamp的数据精度在Oracle的时间类型中是最高的，精确到微秒(还没与到纳秒的级别)，一般来说，加上数据库处理时间和人的思考动作时间，微秒级别是非常非常够了，其实只要精确到毫秒甚至秒都应该没有什么问题。和刚才的版本戳类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。如果不想把代码写在程序中或者由于别的原因无法把代码写在现有的程序中，也可以把这个时间戳乐观锁逻辑写在Trigger或者存储过程中。