如何解决一个并发性能瓶颈的问题

zhengqin1907

在一个事务很长的procedure中有一个执行时间很短的subprocedure，但这个subprocedure会锁住很频繁访问的数据记录进行更新，这样导致了整个procedure 的并发性能很差。

由于subprocedure更新的数据并无业务意义，所以我考虑将subprocedure放在独立的事务中处理

于是我在subprocedure中加入了
BEGIN WORK;
.....
COMMIT WORK;

但在程序运行时，系统会给我一个错误提示，transaction already exist
显然这种方法不行。

不知道有什么方法可以解决这一并发性的问题

谢谢

前面提过这一问题，但没问对要点，所以重新编辑了此问题，见谅

mywg

我建议不要这样干，我曾经有过一次类似的经历：
使用了嵌套的事务，在个别系统繁忙的时候出现个别事务回滚不完整的情况，调试了1个月才实际定位了错误，十分悲惨！

zhengqin1907

我也不想用嵌套的事务，只想subprocedure中是个独立的事务。
只所以想这样做是因为我的subprocedure中会锁住很频繁访问的数据记录，这条记录的更新无需受parent procedure 事务是否成功失败的影响。但parent procedure 是一个很长的事务，如果都在同一个事务里面，会导致这个应用的并发性很差。

wuyong

我也遇到过，通过跟踪查出有问题的记录删掉/更正就好了！

ifx

事务不可能嵌套。而有时候形成的“嵌套”应该是多步提交造成的，并不是真正意义上的嵌套

zhan_yl

你能不能考虑将你的subprocedure从你的parent procedure 中脱离出来，进行分步提交，或者考虑一下你频繁使用的表的锁机制，如果使用的是行级锁可以改善并发性能

zhengqin1907

不幸的是，这个subprocedure无法分离。
我使用的是行锁。但subprocedure中每次更新的也是同一行，所以仍会锁住。