在Oracle中如何实现读锁

xiaodong_1567

精细访问控制特性原来真的不熟
学习了

jidongzheng

好东东。

flying.hg

学习了!

zhaolinjnu

首先不论此需求的合理性，对于此需求的实现，这里有另外一种思路？

首先创建另外一张表，插入一条类似下面这样的记录：
insert into select_ctl(table_name,lock_start,lock_end,status) values('TEST',SYSDATE,SYSDATE,0);
这张表可以称为对Test表的select查询访问控制表，status有两个状态：0 未锁定；1 锁定中

当要进行select查询时:
1.更新控制表select_ctl中的记录 update select_ctl set lock_start=sysdate,lock_end=null,status=1 where table_name='TEST' and status=0;
commit;
2.判断更新的结果集行数，如果为1，则进行相要的select查询（如果为0,则在应用层等待一下，再次返回到第一步中的更新）：
    比如说: select * from test;
3.查询完成后，更新控制表select_ctl,以便其它的会话可以进行查询
  update select_ctl set lock_end=sysdate,status=0 where table_name='TEST' and status=1;
  commit;


如果这类的需求一定要处理,并且采用此设计实现，可以对select_ctl表中的记录进行监控。

棉花糖ONE

原帖由 zhaolinjnu 于 2008-6-9 16:36 发表
首先不论此需求的合理性，对于此需求的实现，这里有另外一种思路？

首先创建另外一张表，插入一条类似下面这样的记录：
insert into select_ctl(table_name,lock_start,lock_end,status) values('TEST',SYSDATE,SYSDATE,0);
这张表可以称为对Test表的select查询访问控制表，status有两个状态：0 未锁定；1 锁定中

当要进行select查询时:
1.更新控制表select_ctl中的记录 update select_ctl set lock_start=sysdate,lock_end=null,status=1 where table_name='TEST' and status=0;
commit;
2.判断更新的结果集行数，如果为1，则进行相要的select查询（如果为0,则在应用层等待一下，再次返回到第一步中的更新）：
    比如说: select * from test;
3.查询完成后，更新控制表select_ctl,以便其它的会话可以进行查询
  update select_ctl set lock_end=sysdate,status=0 where table_name='TEST' and status=1;
  commit;


如果这类的需求一定要处理,并且采用此设计实现，可以对select_ctl表中的记录进行监控。

你这么设计是会出问题的,select 和update select_ctl表之间这个时间点,如果有另一个人也访问行,一样是能同时读到行,同时commit还得进行做日志同步,如果log file sync的等待很严重,这时候出现大家同时访问一行的概率就越大,这么设计必然导致commit频繁

[ 本帖最后由 棉花糖ONE 于 2008-6-9 16:47 编辑 ]

棉花糖ONE

真搞不懂做读阻塞读的意义在哪

stronghearted

原帖由 棉花糖ONE 于 2008-6-9 16:44 发表


你这么设计是会出问题的,select 和update select_ctl表之间这个时间点,如果有另一个人也访问行,一样是能同时读到行,同时commit还得进行做日志同步,如果log file sync的等待很严重,这时候出现大家同时访问一行的概率就越大,这么设计必然导致commit频繁

确实存在问题，在高并发的情况下。

stronghearted

不知道在线上库中，有多DB会用FGA？

太消耗资源是最大的问题，撤远了

zhaolinjnu

它这个需求，要实现排它的读锁，本身这张表，访问量应该是不高的吧！

如果访问量很大，不管采用何种实现方式，都会造成很大问题的。

zhaolinjnu

原帖由 棉花糖ONE 于 2008-6-9 16:44 发表


你这么设计是会出问题的,select 和update select_ctl表之间这个时间点,如果有另一个人也访问行,一样是能同时读到行,同时commit还得进行做日志同步,如果log file sync的等待很严重,这时候出现大家同时访问一行的概率就越大,这么设计必然导致commit频繁

至于log file sync会很严重的问题，稍微变一下程序逻辑就可以解决，

因为如果更新的结果集为0条，则不需要进行commit操作。