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

Question

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

之类的物理事务中

开始交易

//pessimistic locking

提交交易 ？

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

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

Answer 1

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

如果允许许多用户编辑一个用户提交的帖子，则应使用某种版本控制系统。或者，如果您希望使用锁定系统，则可以创建一个系统，该系统保留正在编辑的帐户以及正在编辑的内容，并定期从客户端更新此信息。就像每隔一分钟一次，如果服务器在两分钟内没有收到客户端的任何消息，则释放锁。

Answer 2

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

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

在上述情况下，直到用户整个对话期间都不会保留任何数据库资源。 一般来说，在这种情况下乐观锁定是好的。

但是，如果在事务提交之前用写锁来保存资源非常关键，则应使用伪类

例如，假设有一个简单的电影票预订系统，该系统不为尚未付款的用户保留小票。意味着付款后他们可能会也可能不会获得门票。付款后，他们会要求预订引擎预订机票。

1. 假设db中有一个表，该表保存了show中剩余的种子数量。
2. Tx1对此表具有假想的写锁。
3. 在事务TX1预订电影之前，没有其他事务可以提交 锁上这张桌子。
4. Tx1完成后，它会根据Tx1中预订的座位数减少座位数
5. 现在当Tx2获得写锁定并且如果剩余的导引数兼容时 如果不是，则继续处理，向用户显示一条消息，提示其他人已预订座位 用户和付款已退还。

在这种情况下，直到预定交易完成之前，保持假锁是有意义的。即使在这种情况下，用户的账户中也不会保留任何锁和交易。 完全妥协。

将保留悲观读取或伪写入锁，直到事务提交或回滚为止。只能共享伪读锁，所有其他组合将互相阻塞，直到释放为止。