其实去年做一个小型论坛的时候接触过这个方面的问题,当时也提出了一个解决方案,但由于没有大量的并发测试,所以不知道效果到底如何。
使用这个应该没有问题了,等过段时间上线了再测试下。如果研究过这个发面的高手路过,求指教求学习
其实主要的问题就是集中在那个楼层计算上面。在前台页面显示有如下两种情况:
- 第几个回复就是第几楼。在数据库不保存楼层数,直接在前台输出的时候计算显示楼层。因此在有删除回复的情况下,楼层数是可变的,这样不利于楼层回复。
- 按照回复的顺序计算楼层。在数据库保存楼层数,即在插入回复时就计算出楼层。这样即使有删除的回复,每个回复的楼层数是不会变的。
所以尽量是要使用第二种情况。
去年的时候提出的解决方案如下:
其中主题表为tbl_post,回复表为tbl_reply
declare @floor int;
select @floor = (select count(*) from tbl_reply where postId = $postId) + 1;
insert into tbl_reply values($postId,$content,$userid,date,@floor,1,0);
Go
但这样其实明眼一看很容易造成冲突,因为没有给tbl_replay加修改锁,很有可能几个回复会得到同一楼层
于是这次又涉及到这个内容后,查询了一些资料,改进如下:
其中主题表为tbl_post,回复表为tbl_reply
BEGIN TRANSACTION
DECLARE @errorSun INT
SET @errorSun=0
select * from zb_reply with (UPDLOCK); --给zb_reply表加修改锁
declare @floor int;
select @floor = (select count(*) from zb_reply where pid = $pid) + 1; --计算楼层
insert into zb_reply values($pid,$content,$userid,date,@floor,1);
SET @errorSun=@errorSun+@@ERROR
update zb_post set reply = reply + 1 where pid = ".$pid."; --给主题表添加回复数
SET @errorSun=@errorSun+@@ERROR --错误处理
IF @errorSun<>0
BEGIN
ROLLBACK TRANSACTION
END
ELSE
BEGIN
COMMIT TRANSACTION
END
使用这个应该没有问题了,等过段时间上线了再测试下。如果研究过这个发面的高手路过,求指教求学习