数据库异常后的SQL超时

Posted 2021-05-05

我在我的ASP.NET web应用程序中使用Castle ActiveRecord作为我的ORM。我正在使用他们的SessionPerRequest方法，这很好用。但是，如果在数据库级别发生错误（例如，删除项目时出现约束错误或截断错误（字符串或二进制数据将被截断）。）我会在错误发生后运行所有查询时不断超时。这发生了大约十分钟，然后一切都运行良好。我认为这与交易没有正确关闭有关。我似乎找不到在错误发生后正确关闭事务的方法，所以我现在正在寻找最小化效果的方法。我已经尝试将命令超时和连接超时设置为较小的数字，但这似乎不起作用。有没有人知道如何解决这个问题？

答案

据我了解你的情况，你的问题有两种可能的来源：

1.数据库服务器配置您没有使用我们使用的数据库，所以我只能猜测。如果SQL命令导致锁定，则它们可能正在等待导致异常的旧命令，并且永远不会解析（也称为TimeOut）。如果事务存储在日志文件中，则日志文件可能在物理上已满（非常不可能），并且在解决导致异常的旧命令（也称为TimeOut）之前，不能存储将来的命令。根据数据库系统的不同，可能存在其他原因导致的错误。以eiter的方式，它很容易测试，如果它是由数据库引起的，那么你只需用SQL命令启动一个新的请求，没有NHibernate，而且更适合数据库专家。如何测试，如果是数据库配置问题？简单。您只需要导致错误，然后使用管理工具（例如MS SQL Server Management Studio，Oracle SQL Developer等）发送与您的软件发送相同的SQL命令。如果管理工具中的此命令与您的软件存在相同的问题，那么这是一个基于数据的配置问题，您应该只能在数据库中重现和解决它。如果管理工具中的comman在没有超时的情况下解析，则问题出在软件的代码或配置中。

2. SessionPerRequest无法正常工作我认为“大约需要10分钟”，这意味着在不使用软件10分钟后（问题四舍五入），问题就会停止。我还猜测，如果你不断向浏览器发送新的请求到服务器（IIS），问题将持续超过10分钟。这意味着，IIS-web-session或IIS-应用程序池（由您的软件使用）都会出现超时，并处理掉每个静态变量，每个会话变量以及存储在其中的每个NHibernate会话。那里！如果您想使用SessionPerRequest解决方案来避免此问题，那么您必须自己实现SessionPerRequest方法！ ！您必须在应用程序中创建一个代码，该代码在请求开始时创建一个新的NHibernate会话，并在请求结束时处理它自己的NHiberante会话，这不会编码到NHibernate本身并且无法激活任何配置，你必须自己编码。

问候Juy Juka