我有一个sql server(server1)和webservice server(server2)。 server2有以下代码。从客户端获取结果请求并更新数据库。
try
{
AppLogger.DebugFormat("Entered into save result - [{0}]", result.ID);
int retry = 0;
while (++retry <= 5)
{
try
{
using (var oConnection = new SqlConnection("Connection string"))
{
oConnection.Open();
AppLogger.Debug("Saving data into db");
oConnection.Execute("storedproc1", new
{
param1 = Convert.ToInt32(result.value1),
param2 = Convert.ToInt32(result.value2),
param3 = result.value3=="Success",
param4 = result.vaue4
}, commandType: CommandType.StoredProcedure);
AppLogger.DebugFormat("Save done with [{0}] try", retry);
break;
}
}
catch (SqlException sx)
{
if (retry == 5)
{
AppLogger.Debug("sql exception occured");
throw;
}
else
{
AppLogger.ErrorFormat("Exception occurred [{0}] time(s), going to retry again after a minute", sx, retry);
System.Threading.Thread.Sleep(1000 * 60);
}
}
}
}
catch (Exception ex)
{
AppLogger.Error("Unable to save result", ex);
throw;
}
webservice服务器(Server2)正面临蓝屏错误而死亡。我们重新启动它,并从应用程序中找到以下日志信息。
10:32:41.046 Entered into save result - 100023
10:32:41.062 Saving data into db
10:32:41.062 Save done with 0 try
10:32:45.233 Entered into save result - 100024
10:32:41.248 Saving data into db
10:32:41.248 Save done with 0 try
但是sql server(server1)没有此更新。
以下是我的存储过程
Alter Procedure storedproc1
@Param1 int,
@Param2 int,
@Param4 varchar(2000),
@Param3 bit
AS
SET NOCOUNT ON
BEGIN
Declare @param5 varchar(30)
select @param5=col1 from table1 where col2=@param1 and col3=@param2
UPDATE table1 set col4=@param3, col5=@param4 where col2=@param1 and col3=@param2
IF not exists (select 1 from table1 where col1 = @param5 and col5 is null and col4 is null)
BEGIN
UPDATE table2 set col2='statuschange'
where col1 in (select distinct col6 from table1 where col1=@param5)
END
END
有人可以指出为什么应用程序服务器说保存完成并且sql server没有更新?
sql server是否会回滚连接丢失的变化?
顺便说一下,我用dapper与我的数据库交谈。 Log4net常用日志记录。
谢谢你的时间, 也先
答案 0 :(得分:2)
通常,如果在连接丢失时,事务处于打开状态,则该事务将完全回滚。另一方面,如果事务已提交,则即使在提交后服务器崩溃,其更改也将继续存在。
您的代码未显示任何交易处理。如果在没有显式事务的情况下执行SQL代码,则每个语句都在自己的自动事务中运行因此,每个完成的语句都将被保留。
您看到的行为指向正在使用的交易而未正确清理。这与事务池一起可能会导致意外行为。
跟踪此问题的一种方法是在SELECT @@TRANCOUNT;
块的开头执行using(var oConnection)
。如果这回到了预期的高位,你就会遇到问题。它需要始终为0
,或者如果dapper设置为在事务内部执行代码,则它必须始终为1
。任何大于“默认”的值都指向事务泄漏。