Object_id:表示被锁对象标识。
Session_id:表示持有锁的会话信息。
Locked_mode :表 示会话等 待的锁模 式的信息 ,和
v$lock 中的 lmode 一致。
二、 锁的探讨
在我们讨论之前先来看一个关于锁的问题,这些问题大多都是因为那些设计不好的应用程序错误的使用(或没有使用)数据
库锁机制引起的。
1、更新丢失
“更新丢失”是一个典型的数据库问题,在所有的多用户环境都可能遇到。简单的描述下“更新丢失”的产生:
1)session1 的一个事务查询一行数据展现给 user1。
2)另一个 session2 的一个事务也查询同一行数据展现给 user2。
3)然后 user1 通过应用程序更新并提交这行数据,他完成了整个事务。
4)User2 也同样通过应用程序更新并提交这行数据,他也完成了整个事务。
上面的过程就会造成“更新丢失”,因为所有在第三步修改的数据全部都会丢失。一个典型的例子就是售票系统,比如一个用
户(user1)在网上预定查询到 1 号位的票还没售出,同时另一用户(user2)在现场售票点查询也查到 1 号位票没售出。然后
user1 预订了这张票(即售票系统更新了数据库表中 1 号位的信息“已预订”),而这时 user2 又将这张票卖给了现场购票的人(即
user2 也成功更新 1 号位的信息“已售”,覆盖更新了 user1 的更新),等到 user1 去拿票的时候他预定的票却已经被卖出去了,这
就是应用系统出现的一个严重的问题。
2、悲观锁
“悲观锁”实际上是一种使用锁的方式,即 user1 主观的认为会发生“更新丢失”,所以在他查询的时候就对查询结果的数据“立
刻”加锁来防止发生“更新丢失”。这是一种“悲观”的想法,所以叫做“悲观锁”。
“悲观锁”一般用于独占连接的数据库环境,至少是一个用户在一个事务的生存周期中独占这个连接,比如 C/S 这种结构的系
统中。下面模拟下应用中如何使用“悲观锁”:
Session1:
//session1 应用程序先查询信息(不加锁)
SQL> select * from test1;
ID NAME SEX
---------- ------------------------------ --------------------
100 iceberg3521 male
101 singlelove male