我正在使用Delphi IBQuery和IBTransaction组件通过此查询更新数据库中的所有记录:

UPDATE INVOICES SET BLK = 0;


当用户离开另一个客户端应用程序打开时,它将在某些记录(由用户打开)上留下死锁。

问题是我的应用程序必须完成上面的查询。

是否有可能实施某种解决方案来强行清除死锁?例如一个SQL查询?

Firebird版本为2.1.2.18118
在Windows 7上运行

最佳答案

最好的选择是重构那些应用程序。

FB / IB的自然模式是具有两个并行事务。


#1将是只读的,已提交的,永不关闭的,它将仅用于读取数据。
#2将短暂打开/提交以实际应用更改。任何“编辑中”的数据本身都不会打开交易。


长期的编辑事务通过阻止垃圾收集并强制其(和索引)包含大量虚假数据来影响数据库。

我不知道您是否可以通过IBX + IBQuery +某种自定义更新查询(例如TUpdateSQL)来完成bDE时代。第三方FB连接库通常对双向事务模式提供一些支持。

但是,这种方法对应用程序的设计施加了非常特殊的模式,并使Firebird无法保证数据的一致性-这现在是应用程序的负担。这些评论带来了一个不错的链接:http://tech.groups.yahoo.com/group/firebird-support/message/94903



在现代Firebird中,如果您具有数据库管理员/所有者角色,则可以强制删除事务。了解有关监视表的信息。请注意,2.5.1中存在错误,因此您可能需要等待2.5.2发布。


http://www.upscene.com/documentation/fbtm2/index.html?dm_monitoringtables.htm
c:\ Program Files \ Firebird \ Firebird_2_5 \ doc \ README.monitoring_tables.txt


但是,如果您强制回滚这些事务,那么应用程序将如何运行?用户仍然在编辑,只是突然发现他的大部分更改都丢失了。

PS。 http://www.sql.ru/forum/actualthread.aspx?tid=910920此代码使用mon$transactions将事务映射到连接,然后强行断开有问题的应用程序。如果直接delete from mon$transactions where...不可用,则剩下的选项是。

PPS。由于FB 2.1的长期事务最好每隔几分钟(甚至是r / o事务)进行一次提交(并关闭)。原因是它们是否恰巧使用BLOB计算,这可能导致只能通过关闭事务重置数据库而无法控制的增长。虽然这可能会触发重新读取所有支持数据库的控件,但无需像MIDAS ClientDataset这样的中间缓存就可以处理事务,但这可以说比数据库膨胀还好,在极少数情况下,报告速度非常快。

10-07 15:54
查看更多