关于select count() 和insert

沉默的拖把 发布于 2013/06/03 10:19
阅读 184
收藏 0
表T1中记录了用户每次行为的类型和时间,
表T2记录了用户不同类型行为的限制周期和限制次数(比如限一天一次,一周三次)。
如果T1的select count()没有超过T2限制,就往T1里插入一条记录。
这个逻辑在并发时候会无视T2的限制条件,怎么解决呢
加载中
0
R-Lu
R-Lu
那就并发锁表,一条条来,只能这样了.
0
hylent
hylent
缓存T2
沉默的拖把
沉默的拖把
现在在用的临时方案就是缓存,实在不行就这么着了
0
沉默的拖把
沉默的拖把

引用来自“Robinson_lu”的答案

那就并发锁表,一条条来,只能这样了.

select for update 吗

这样不能防止insert吧

0
R-Lu
R-Lu

引用来自“沉默的拖把”的答案

引用来自“Robinson_lu”的答案

那就并发锁表,一条条来,只能这样了.

select for update 吗

这样不能防止insert吧

select和insert同一个事务,先查询,如果锁定了,后面的insert就不用做了.
沉默的拖把
沉默的拖把
回复 @Robinson_lu : hibernate的悲观锁么,那个应该就是for update来着
R-Lu
R-Lu
难道要使用悲观锁,按理说锁表已经很不对了,不会要锁库吧.猜测...
沉默的拖把
沉默的拖把
之前就是这么做出的问题 测试类用多线程跑500条,仍是有数十条突破限制insert进去了
0
jhting
jhting

如果你的select count 和insert做为一个动作还会这样吗?

像下面这样?

insert into ... value (select ... from where...)


沉默的拖把
沉默的拖把
多线程跑的测试也是为了以后分布式和高并发访问做的准备,看来缓存还是最简单暴力的了。多谢回复
jhting
jhting
回复 @沉默的拖把 : 如果你分开的查询,多个线程没有一个互斥的写入读出保证,怎么可能不出现那样的问题呢?这样也没有什么多线程的优势吧,你读写库就是一个I/0操作,那也得线程排队呀,那还是得用缓存吧!
沉默的拖把
沉默的拖把
这样改动就太大了,整个事务里也不止这几条SQL
返回顶部
顶部