简短的答案,这确实不是所提出的Django问题。
并发控制通常是一个技术问题,但在许多方面却是功能需求问题。您希望/需要您的应用程序如何工作?在不知道这一点之前,很难给出任何特定于Django的建议。
但是,我感觉很漫无边际,所以这里…
当面对并发控制的需求时,我倾向于问自己两个问题:
- 两个用户需要同时修改同一记录的可能性有多大?
- 如果丢失了对记录的修改,对用户有什么影响?
如果冲突的可能性相对较高,或者丢失修改的影响严重,那么您可能正在寻找某种形式的悲观锁定。在悲观方案中,每个用户必须在打开记录进行修改之前获得逻辑锁。
悲观锁定会带来很多复杂性。您必须同步对锁的访问,考虑容错性,锁到期,超级用户可以覆盖锁,用户可以看到谁拥有该锁,等等。
在Django中,可以使用单独的Lock模型或锁定记录上的某种“ lock
user”外键来实现。使用锁表在获取锁时,用户,便笺等方面的存储方面具有更大的灵活性。如果您需要可用于锁定任何类型的记录的通用锁表,请查看django.contrib.contenttypes框架,但是很快它可以演变为抽象的宇航员综合症。
如果冲突不太可能或丢失的修改被重新创建,那么您可以在功能上摆脱乐观并发技术的束缚。该技术简单易行。本质上,您只需跟踪版本号或修改时间戳,并拒绝您发现的任何修改。
从功能设计的角度来看,您只需要考虑如何将这些并发的修改错误呈现给用户。
对于Django而言,可以通过覆盖模型类上的save方法来实现乐观并发控制。
def save(self, *args, **kwargs): if self.version != self.read_current_version(): raise ConcurrentModificationError('Ooops!!!!') super(MyModel, self).save(*args, **kwargs)
而且,当然,要使这两种并发机制都健壮起来,就必须考虑事务控制。如果您不能保证交易的ACID属性,则这两种模型都无法完全使用。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)