考虑一个网页,其网格视图连接到SqlDataSource,具有插入更新和删除的所有权限。
发布网页。
这一切都在一台本地计算机上
现在
现在我在两个浏览器中编辑并逐个按下更新没问题
最后一次更新是保留的。
但假设情况:
计算机可以同时运行两个应用程序
两位用户都准备好了,同时在浏览器中按下更新
即使您考虑使用两台不同的计算机,但对于这个问题,这是不可能的
尽可能考虑
从两个不同的源更新到同一个数据库同一个表同一行
同时,同样的秒,同样的微秒没有延迟,两者同时打到数据库服务器。
会发生什么?
理论上我已经研究过数据库管理软件在写入无读取,没有其他写入等时实现锁定,但SQL Server 2005 Express实际上是否实现了锁定,还是假设上述情况永远不会发生?
如果在那里锁定,请提供解释或资源,以解释它保持不同的访问方案
谢谢
编辑 : - 我没有像sqldatasource那样使用控件,所以请通过提供语句来避免更新
它像 - 算法---
sqlconnection conn=new .....
sqlcommand
command text is "sql statement for updating values of a particular row"
conn.Open();
cmd.ExecuteNonQuery();
conn.close;
以便我看到如何定义在执行initquon之前的检查,如果最近更改了数据,您确定要继续吗?什么
我觉得我有点困惑...... }
答案 0 :(得分:2)
大多数使用Optimistic Concurency control的应用程序都解决了这个问题。应用程序只是向更新WHERE子句添加更多条件,以便检测在读取数据和应用更新之间发生的更改。被称为乐观的可靠性,因为应用程序假定不会发生任何更改,如果它们确实发生,则会检测到它们并且appplicaiton必须重新启动操作。乐观的可靠性的替代方案是pesimistic concurency,其中应用程序显式锁定它计划更新的数据。在实践中,涉及用户交互的操作在pesimistic concurency模型下从不完成。
其他可靠性模型,特别是在分布式应用程序中,是Fiefdom and Emissaries模型隐含的模型。
因此,虽然数据库锁和事务可靠性模型在任何数据库操作中总是无处不在,但当涉及用户交互时,任何应用程序都不会依赖于数据库锁。就数据库事务而言,用户交互只是简单的方法。为健忘的人获取锁定弗雷德出去吃午饭并在他的桌面上打开数据屏幕根本不起作用。
答案 1 :(得分:1)
SQL 2005将强制执行锁定。在更新行之前,事务必须获取对它的独占锁定。 Only 1 transaction can be granted this at a time所以另一个必须等待该事务提交(2 phase locking),然后才能获得更新所需的锁。
第二次写入将“赢”,因为它将覆盖第一次。您可以在sqldatasource中实现optimistic concurrency controls以检测该行已更改并中止第二行,而不是盲目地覆盖第一个编辑。
修改强>
在澄清问题之后。如果你想自己滚动,你可以在表格中添加一个timestamp列(在SQL Server 2005中,这会在更新行时自动更新),然后在网格视图中将其作为隐藏数据项返回,然后在更新中语句添加where子句UPDATE ... WHERE PrimaryKeyColumn=@PKValue AND TimeStampCol=@OriginalTimestampValue
如果没有行受到影响(可从ExecuteNonQuery中检索 - generally),则另一个事务修改了该行。这可能比数据源控件使用的替代方法更轻量级,它将所有列的原始值传回,并将它们添加到具有类似逻辑的WHERE子句中。