-
-
兰兰
-
Oracle中，我不知道悲观锁和乐观锁，不经常这么叫的吧？
只知道你说的排它锁之类的。
|
回复于： 2011-09-01 16:22:59
#1得分：4
|
-
-
wuhuipengwhp
-
有悲观锁也有乐观锁的
|
回复于： 2011-09-01 16:37:47
#2得分：2
|
一天十小时
能否举个乐观锁的例子？在oracle 数据库中的。
|
回复于： 2011-09-01 17:40:55
#3得分：0
|
-
-
youshang444
-
加悲观锁就不会有丢失更新的问题，但有可能会影响 性能！
|
回复于： 2011-09-01 20:05:17
#5得分：2
|
-
-
wffffc
-
sql>desct
名称是否为空?类型
-------------------------------------------------------------------
INUMBER(38)
sql>select*fromtwhererownum=1;
I
----------
258
sql>updatetseti=255wherei=258;
已更新1行。
update语句里面加where条件，tom书里面说的大概就是这个意思。
|
回复于： 2011-09-01 21:27:06
#6得分：5
|
引用6楼wffffc的回复:
SQL>desct
名称是否为空?类型
-------------------------------------------------------------------
INUMBER(38)
SQL>select*fromtwhererownum=1;
I
----------
258
SQL>updatetseti=255wherei=258;
已更新1行。
update语句里面加where条件，tom书里面说的大概就是这个意思。
没看出哪里加了乐观锁啊？update语句加where条件就是乐观锁？
回复于： 2011-09-02 08:57:20
#7得分：0
|
-
-
咖啡
-
孤陋寡闻了，还真没听过这种说法，我只知道共享锁和排他锁。
|
回复于： 2011-09-02 09:17:39
#8得分：2
|
-
-
天梯
-
oracle有悲观锁也有乐观锁。悲观锁比较安全一些，可以防止丢失更新，但是就是互相等待，影响效率。
一般会用乐观锁，即开始操作时，乐观的认为数据不会被其他人更改，直到提交时才加锁检查。比如在操作的表上加一列，保存个时间戳，提交时检查是不是最新的。不过乐观锁失败的可能性比较大。
|
回复于： 2011-09-02 09:27:05
#9得分：5
|
-
-
yuhck39
-
Exclusivelocks
|
回复于： 2011-09-02 23:06:38
#10得分：2
|
-
-
fanxiaohe123
-
乐观锁用白话一点说：先改，改了再说，要是别人 修改过了我就不再改了，要改也得重新查再改
一般是表共享，行排他
最好是乐观锁，因为效率，但当C/S结构时，悲观的好。
（都是自己的个人看法）
|
回复于： 2011-09-06 18:54:38
#11得分：6
|
引用11楼fanxiaohe123的回复:
乐观锁用白话一点说：先改，改了再说，要是别人修改过了我就不再改了，要改也得重新查再改
一般是表共享，行排他
最好是乐观锁，因为效率，但当C/S结构时，悲观的好。
（都是自己的个人看法）
在oracle数据库里，举个乐观锁的例子？
回复于： 2011-09-07 08:03:53
#12得分：0
|
-
-
胖胖_多多
-
乐观锁，大多是基于数据版本（Version）记录机制实现。
数据版本即为数据 增加一个版本标识，在基于 数据库表的版本 解决方案中，一般是通过为 数据库表 增加一个“version”字段来实现。
读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与 数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于 数据库表当前版本号，则予以更新，否则认为是过期数据。
对于上面 修改用户帐户信息的例子而言，假设 数据库中帐户信息表中有一个version字段，当前值为1；而当前帐户余额字段（balance）为$100。
1操作员A此时将其读出（version=1），并从其帐户余额中扣除$50（$100-$50）。
2在操作员A操作的过程中，操作员B也读入此 用户信息（version=1），并从其帐户余额中扣除$20（$100-$20）。
3操作员A完成了 修改工作，将数据版本号加一（version=2），连同帐户扣除后余额（balance=$50），提交至 数据库更新，此时由于提交数据版本大于 数据库记录当前版本，数据被更新， 数据库记录version更新为2。
4操作员B完成了操作，也将版本号加一（version=2）试图向 数据库提交数据（balance=$80），但此时比对 数据库记录版本时发现，操作员B提交的数据版本号为2， 数据库记录当前版本也为2，不满足“提交版本必须大于记录当前版本才能执行更新“的乐观锁策略，因此，操作员B的提交被驳回。
这样，就避免了操作员B用基于version=1的旧数据 修改的结果覆盖操作员A的操作结果的可能。
乐观锁机制避免了长事务中的 数据库加锁开销，大大提升了大并发量下的系统整体 性能表现。
|
回复于： 2011-09-07 09:17:40
#13得分：6
|
胖胖_多多
补充一下
在乐观锁中，常用的 实现方法有3种。
[1]第一种就是在数据取得的时候把整个数据都copy到应用中，在进行提交的时候比对当前 数据库中的数据和开始的时候更新前取得的数据。当发现两个数据一模一样以后，就表示没有冲突可以提交，否则则是并发冲突，需要去用业务逻辑进行 解决。
[2]第二种乐观锁的做法就是采用版本戳，就是我上边说的那个[#13楼]
[3]第三种做法和第二种做法有点类似，就是也新增一个Table的Column，不过这次这个column是采用timestamp型，存储数据最后更新的时间。在Oracle9i以后可以采用新的数据类型，也就是timestampwithtimezone类型来做时间戳。这种Timestamp的数据精度在Oracle的时间类型中是最高的，精确到微秒(还没与到纳秒的级别)，一般来说， 加上数据库处理时间和人的思考动作时间，微秒级别是非常非常够了，其实只要精确到毫秒甚至秒都应该没有什么问题。和刚才的版本戳类似，也是在更新提交的时候检查当前 数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。如果不想把 代码写在程序中或者由于别的原因无法把 代码写在现有的程序中，也可以把这个时间戳乐观锁逻辑写在Trigger或者存储过程中。
|
回复于： 2011-09-07 09:29:31
#14得分：6
|
一天十小时
楼上只说了乐观锁的原理。能否说一下 数据库
如何加乐观锁？
|
