我在我的ASP.NET web应用程序中使用Castle ActiveRecord作为我的ORM。我正在使用他们的SessionPerRequest方法,这很好用。但是,如果在数据库级别发生错误(例如,删除项目时出现约束错误或截断错误(字符串或二进制数据将被截断)。)我会在错误发生后运行所有查询时不断超时。这发生了大约十分钟,然后一切都运行良好。我认为这与交易没有正确关闭有关。我似乎找不到在错误发生后正确关闭事务的方法,所以我现在正在寻找最小化效果的方法。我已经尝试将命令超时和连接超时设置为较小的数字,但这似乎不起作用。有人知道如何解决这个问题吗?
答案 0 :(得分:0)
据我了解您的情况,您的问题有两种可能的来源:
<强> 1。数据-BASE-服务器的配置强> 你没有使用我们使用的数据库,所以我只能猜测。如果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