2013-05-01 39 views
0

我在Azure SQL中有一个包含多条记录的表。该表中的数据通过实现多个读/写方法的API层(基于实体框架)公开。此API层封装在支持多个实例的工作者角色中。我有一个应用程序(一个桌面应用程序,而不是一个Web角色),它可以在不同的客户端机器上同时运行。这个应用程序进行2个特定的调用 - 一个读取,另一个使用上述API编写。这两个调用都将从Azure SQL表中访问相同的记录。我正在寻找实施锁定机制,以防止多个客户端尝试使用我的应用程序读取相同的记录。然而,这个记录级别的读取锁定只适用于一个特定的读取调用(由API公开的许多)。虽然我已经想出了如何锁定记录,但我不确定如何实现特定于某个特定呼叫的锁定。当我们认为实现API的worker角色有多个实例在运行时,这会变得更加复杂。仅当通过特定调用访问时锁定Azure SQL记录

到目前为止,我考虑的一些想法:

  1. 存储过程:Entity Framework - Read Lock on Record。这会遇到仅为特定读取调用锁定行的问题。
  2. 我的应用程序使用的API读取调用中的关键部分锁定。然而,当工作者的多个实例正在运行时,这不会起作用,因为临界区段锁只会在实例级别。
  3. 使用额外的IsProcessing列,在进行第一次读取时将被标记为true。这可以与idea-1和/或idea-2结合使用。
  4. 重构,读取我在API中使用的调用来实现row level locking。由于我的应用程序是唯一使用此特定读取调用的应用程序,因此这可能是一种可能的解决方案,但是,如何才能为此调用启用锁定,因为来自其他API调用的其他读取操作应该仍然成功......还有物流由于这个想法是绝对的最后的手段,我真的不希望如果可能的话实施。

任何指针表示赞赏。

UPDATE:

使用在特定的互斥读叫我的应用程序使用似乎是一个可能的解决方案。

回答

1

我不会质疑你为什么要这样做,但由于复杂程度的原因,我远离这种类型的设计,而通常实现乐观并发。

要直接回答你的问题,我可能会实现Windows Azure缓存,如果这对你的设计有意义的话,可能会有一个到期窗口。您可以将主键(PK)值放入缓存中,并在返回记录之前验证该值是否在缓存中或不在API中。如果是,则不返回记录;它不是,你允许读取并将PK放入缓存中。

+0

我最终做了一些类似于在我的API代码中涉及互斥体的建议,以及从表中读取对象/记录的其他IsProcessing属性/列。 – Manas 2013-05-14 00:46:09