我有以下场景:

• 用户 X 从位置 lc1 登录到应用程序:将其命名为 Ulc1
• 用户 X(已被黑客入侵，或者他的某个 friend 知道他的登录凭据，或者他只是从他机器上的其他浏览器登录，等等。你明白了)同时从位置 lc2 登录: 称之为 Ulc2

我正在使用一个主 servlet，它:
- 从数据库池中获取连接
- 将自动提交设置为 false
- 执行通过应用程序层的命令:如果全部成功，在“finally”语句中将自动提交设置为真，并关闭连接。否则如果发生异常，rollback()。

在我的数据库 (mysql/innoDb) 中，我有一个“历史”表，其中包含行列:
id(主键) |用户名|日期 |话题 |锁定

“锁定”列的默认值为“假”，它用作标记特定行是否锁定的标志。
每一行都特定于一个用户(正如你可以从用户名列中看到的那样)

所以回到场景:
-->Ulc1 发送命令以更新他从数据库中获取日期“D”和主题“T”的历史记录。

-->Ulc2 发送 same 命令以更新 来自数据库的相同 日期“D”和相同的历史记录 同一时间的主题“T”。

我想实现一个 mysql/innoDB 锁定系统，使任何到达的线程都能执行以下检查:

此行的“锁定”列是否为真？

• 如果为真，则向用户返回一条消息“他已经从另一个位置更新相同的数据”
• 如果不正确(即未锁定):将其标记为锁定并更新，然后在完成后将锁定重置为 false。

这两种 mysql 锁定技术中的哪一种实际上允许第二个到达的线程读取锁定列的“更新”值来决定采取 wt 操作？

我应该使用 “更新” 或 “锁定共享模式”？

这个场景解释了我想要完成的事情:
- Ulc1 线程先到达:列“锁定”为假，将其设置为真并继续更新过程
- Ulc2 线程到达时 Ulc1 的事务仍在处理中，即使该行通过 innoDb 功能锁定，它也不必等待但实际上读取列锁定的"new"值是“真”，因此实际上不必等到 Ulc1 事务提交来读取“锁定”列的值(无论如何到那时该列的值已经被重置为 false)。

我对这两种锁定机制不是很有经验，到目前为止我的理解是 LOCK IN SHARE MODE 允许其他事务读取锁定的行，而 FOR UPDATE 甚至不允许读取。但是这个读取是否获得了更新的值？或者第二个到达的线程必须等待第一个线程提交然后读取值？

欢迎任何有关在这种情况下使用哪种锁定机制的建议。
此外，如果有更好的方法来“检查”行是否已被锁定(除了使用真/假列标志)，请告诉我。
谢谢

解决方案
(Jdbc 伪代码示例基于@Darhazer 的 回答)

表:[ id(主键)|用户名|日期 |话题 |锁定]

connection.setautocommit(false);
//transaction-1
PreparedStatement ps1 = "Select locked from tableName for update where id="key" and   locked=false);
ps1.executeQuery();

//transaction 2
PreparedStatement ps2 = "Update tableName set locked=true where id="key";
ps2.executeUpdate();
connection.setautocommit(true);// here we allow other transactions threads to see the new value

connection.setautocommit(false);
//transaction 3
PreparedStatement ps3 = "Update tableName set aField="Sthg" where id="key" And date="D" and topic="T";
ps3.executeUpdate();

// reset locked to false
 PreparedStatement ps4 = "Update tableName set locked=false where id="key";
ps4.executeUpdate();

//commit
connection.setautocommit(true);

最佳答案

LOCK IN SHARE MODE 将允许第二个线程读取该值，但实际值将是查询(已提交读)或事务(可重复读取)开始之前的值(因为 MySQL 使用多版本控制; 并且第二个事务必须看到的内容由隔离级别定义)。因此，如果第一个事务在读取时未提交，则将读取旧值。

在您的场景中，最好有 1 个事务使用 select for update 锁定记录，另一个事务处理记录，在提交/回滚时，第三个事务解锁记录。

带有 select for update 的第二个线程事务将等待第一个线程完成，然后读取实际值并决定不继续其他事务，而是通知用户记录已锁定。

为避免死锁，请确保您正在使用唯一索引执行select for update。

示例代码:

connection.setautocommit(false);
//transaction-1
PreparedStatement ps1 = "Select locked from tableName for update where id="key" and   locked=false);
ps1.executeQuery();

//transaction 2
PreparedStatement ps2 = "Update tableName set locked=true where id="key";
ps2.executeUpdate();
connection.setautocommit(true); // here we allow other transactions / threads to see the new value

connection.setautocommit(false);
//transaction 3
PreparedStatement ps3 = "Update tableName set aField="Sthg" where id="key" And date="D" and topic="T";
ps3.executeUpdate();

// probably more queries

// reset locked to false
 PreparedStatement ps4 = "Update tableName set locked=false where id="key";
ps4.executeUpdate();

//commit
connection.setautocommit(true);

关于mysql - "FOR UPDATE"v/s "LOCK IN SHARE MODE": Allow concurrent threads to read updated "state" value of locked row，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9037345/