"FOR UPDATE"v/s"LOCK IN SHARE MODE":允许并发线程读取锁定行的更新"状态"值

Question

我有以下场景:

• 用户X从位置lc1登录到应用程序:将其命名为Ulc1
• 用户X(已被黑客攻击,或者他的一些朋友知道他的登录凭证,或者他只是从他的机器上的其他浏览器登录等等.你明白了)从位置lc2同时登录:调用它ULC2

我正在使用一个主servlet:
- 从数据库池获取连接
- 将autocommit设置为false
- 执行通过app层的命令:如果全部成功,在"finally"语句中将autocommit设置为true,并关闭连接.否则,如果发生异常,则回滚().

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

"已锁定"列默认值为"false",它用作标记特定行是否被锁定的标志.
每行都是特定于用户的(您可以从用户名栏中看到)

回到这个场景:
- > Ulc1发送命令从数据库中更新他的历史记录"日期""D"和主题"T".

- > Ulc2发送相同的命令,以便在同一时间从同一日期"D"和相同主题"T" 的数据库更新历史记录.

我想实现一个mysql/innoDB锁定系统,它将启用任何到达的线程进行以下检查:

此行的列"锁定"是否为真？

• 如果为true,则向用户返回"他已经从其他位置更新相同数据"的消息
• 如果不是真的(即未锁定):将其标记为已锁定并更新,然后重置锁定为false一旦完成.

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

我应该使用"FOR UPDATE"还是"LOCK IN SHARE MODE"？

这个场景解释了我想要完成的任务:
- Ulc1线程首先到达:列"locked"为false,将其设置为true并继续更新进程
- Ulc2线程在Ulc1的事务仍在进行时到达,即使该行被锁定innoDb功能,它不必等待,但实际上读取列的"新"值是"真",因此实际上不必等到Ulc1事务提交读取"锁定"的值"列(无论如何,此列的值已经被重置为false).

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

有关哪种锁定机制用于此方案的任何建议都值得赞赏.
此外,如果有更好的方法来"检查"行是否已被锁定(除了使用真/假列标志),请让我知道它.
谢谢

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

表:[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);

Answer 1

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

在你的场景中,最好有1个事务用select for update锁定记录,另一个用于记录,在commit/rollback第三个用于解锁记录.

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);