与数据库事务的悲观锁定关系

Question

我知道悲观锁定与锁定数据库记录，并在获得锁的“交易”结束时释放它。但这是否意味着悲观锁定是在物理交易中，例如

开始交易

//pessimistic locking

提交事务？

对于一个网页，当用户选择要编辑的记录时，当他按下编辑按钮时，我想悲观地锁定此记录，以便其他人无法更改它，然后在编辑按钮onpress（）事件中，我开始物理事务？

似乎是不可能的，因为编辑过程可能很长......它在整个编辑过程中保持数据库事务（按编辑按钮，在网页中编辑，按保存按钮）悲观锁定？

Answer 1

实际上，对于这种情况，应该使用乐观锁定。它可以按以下方式使用：

1. 用户从UI请求获取要编辑的记录。
2. 服务器选择记录并将它们传递给UI。假设此时要编辑的记录具有版本1。现在数据库连接被释放。没有数据库资源被持有，因为我们不知道用户是否会发出更新请求。
3. 现在用户在UI上编辑数据，并使用在步骤2中发送的原始版本号向服务器请求更新数据。
4. 现在从db连接池中获取一个新的数据库连接，如果db中的原始记录与步骤2中发送到UI的版本相同，则在db中更新记录。在使用发送编辑请求之前，步骤4中存在的记录的版本已更改，您应该要求用户使用新数据再次编辑。

在上述场景中，在用户的整个会话期间，没有数据库资源被保留。一般来说，在这种情况下，乐观锁定是好的。

但是如果在事务提交之前用写锁持有资源非常重要，那么应该使用Pessimitic

例如，假设一个简单的电影票预订系统，它不为尚未付款的用户保留种子。意味着付款后他们可能会或可能不会拿到票。付款后，他们需要预订引擎来预订机票。

1. 假设数据库中有一个表，它保存了一个节目中剩余的座位数。
2. Tx1对此表采取悲观的写锁。
3. 在预订电影的事务TX1提交之前，任何其他事务都不能锁定此表
4. 当Tx1完成时，它会将座位数减少Tx1中预订的座位数
5. 现在，当Tx2获得写入锁定，并且如果剩余的座位数是兼容的，它将继续，如果不兼容，它将向用户显示一条消息，表明其他用户预订了座位，并且退款

在这种情况下，保持悲观锁直到预订事务完成是有意义的。即使在这种情况下，在用户完全同意的情况下，也没有锁和事务被持有。

悲观读锁或悲观写锁被保留，直到事务被提交或回滚。只有悲观读锁可以共享所有其他组合相互阻止，直到释放。

Answer 2

构建这样的锁定系统不是很实用。即使您能够以某种方式执行此操作，也会严重限制允许访问服务器的用户数量。

如果允许许多用户编辑一个用户提交的帖子，则应使用某种版本控制系统。或者，如果您更喜欢锁定系统，那么创建一个系统来保留帐户谁在编辑以及编辑什么，并定期从客户端更新此信息。就像每分钟一次，如果服务器在两分钟内没有听到来自客户端的任何声音，则释放锁。