gpt4 book ai didi

mysql - "FOR UPDATE"v/s "LOCK IN SHARE MODE": Allow concurrent threads to read updated "state" value of locked row

转载 作者:可可西里 更新时间:2023-11-01 07:05:35 25 4
gpt4 key购买 nike

我有以下场景:

  • 用户 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/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com