异步SQL操作

异步SQL操作

问题描述:

我有一个问题,我不知道如何最好地解决。异步SQL操作

我有一个应用程序更新数据库以响应临时请求。其中一项要求特别常见。请求是一个更新,本身很简单,但有一些复杂的先决条件。

  • 对于该请求业务层 第一个请求一组从 数据层的数据。
  • 业务逻辑层评价 从数据库中的数据和从请求 参数,从 这是 确定要执行的动作,并且创建所述请求的响应 (多个)消息。
  • 业务层现在执行 实际更新命令,即请求的目的 。

最后一步是问题所在,该命令取决于数据库的状态,该数据库可能在业务逻辑运行后发生变化。将数据读取的数据锁定在数据库的几次往返中似乎也不是一个好主意。有没有一种“最佳实践”的方式来完成这样的事情? 谢谢!

简单地说,当您执行更新命令时,您担心数据库可能已更改?

然后调用防御性编写的存储过程,只有当数据在被调用时处于可接受状态(通过检查外键引用,数据完整性等)才会更新。

让我知道我是否可以帮助嘲笑这方面的某些方面。

+0

是的,但是这会在存储过程中放入业务逻辑(我希望能够轻松更改)。 – Paul 2010-03-29 13:38:22

+1

@Paul,如果存储过程只是检查以验证数据没有改变,则不行。我会争辩说,如果你在BL中所做的一切都是检查条件以确定更新的正确表/列,那么应该在存储过程中进行更新。 – AllenG 2010-03-29 13:41:47

+0

检查参照完整性和外键是否可行是最佳实践,让db通过结构和元数据隐式支持业务逻辑(而不是明确地通过设计好的过程代码)也是一种很好的做法。 – amelvin 2010-03-29 13:42:03

您可以存储修改的业务对象的原始状态,并将原始对象与其数据库对应项进行比较,以检查是否有任何更改。

如果修改过,那么你要么选择合并在原有基础上,修改,存储(数据库)的物体上,或取消更新,并告诉客户端更新失败。

+1

以下是一些谷歌关键词:上述策略也称为“乐观并发控制”,在其更复杂的化身中,我们也讨论'编排','业务流程管理'和'补偿交易',另请参阅'传奇' 。 另一种方法是在开始事务时锁定数据(整个数据库,或者只是您触摸/看到的,完全锁定或只写锁定),并让所有人等待操作完成 - 这是所谓的“悲观并发控制“。 – ddimitrov 2010-03-29 14:23:19

这是一种困难,因为问题中没有太多细节,所以我只举一个简单的例子,您可能会适用于您的情况。

加载的所有数据,以及最后的更改日期(YYYY-MM-DD HH:MI:ss.mmm)

SELECT AAA,BBB,LastChgDate FROM YourTable WHERE ID=xxxxxx 

做你的业务逻辑

保存数据

UPDATE YourTable SET AAA=aaaaa,BBB=bbbbb WHERE ID=xxxxxx AND LastChgDate=zzzzzz 

如果行数!= 1,那么其他人的错误已经改变了数据,否则数据被保存。

+0

这个* pattern *被称为乐观并发控制:http://en.wikipedia.org/wiki/Optimistic_concurrency_control – 2010-06-02 07:46:02

使用正确的事务隔离模式并在单个数据库事务中执行所有操作(即,在步骤1中启动事务并在步骤3之后执行)。

你的问题有点含糊,但我猜你要么需要SNAPSHOT或READ COMMITTED模式。