У меня есть следующий сценарий:

Пользователь X входит в приложение из местоположения lc1: вызовите егоUlc1Пользователь X (был взломан, или его друг знает свои учетные данные для входа в систему, или он просто входит в другой браузер на своем компьютере и т. Д., У вас есть точка), одновременно входит в систему из местоположения lc2: вызовите егоUlc2

Я использую основной сервлет, который:
- получает соединение из базы данных
- устанавливает автокоммит на false
- выполняет команду, которая проходит через слои приложения: если все прошло успешно, установите для autocommit значение true в операторе "finally" и закройте соединение. Иначе, если произойдет исключение, rollback ().

В моей базе данных (mysql / innoDb) у меня есть таблица «истории», со строками столбцов:
id (первичный ключ) | имя пользователя | дата | тема | запертый

Столбец «заблокирован» имеет по умолчанию значение «ложь» и служит в качестве флага, который отмечает, заблокирована ли конкретная строка или нет.
Каждая строка специфична для пользователя (как вы можете видеть из столбца имени пользователя)

Итак, вернемся к сценарию:
-> Ulc1 отправляет командуОбновить его история из БД для даты "D" и темы "T".

-> Ulc2 отправляеттакой же командоватьОбновить история из БД длятакой же дата "D" итакой же тема "Т" наточно в то же время

Я хочу реализовать систему блокировки mysql / innoDB, которая позволит любому поступающему потоку выполнить следующую проверку:

Столбец "заблокирован" для этой строки, правда или нет?

если true, верните пользователю сообщение, что «он уже обновляет те же данные из другого места»если не верно (то есть не заблокировано): пометьте его как заблокированное и обновите, а затем сбросьте заблокированное на ложное после завершения.

Какой из этих двух методов блокировки mysql фактически позволит 2-му прибывающему потоку прочитать «обновленное» значение заблокированного столбца, чтобы решить, какое действие wt следует предпринять?

Должен ли я использовать"ДЛЯ ОБНОВЛЕНИЯ" или же"LOCK IN SHARE MODE"?

Этот сценарий объясняет, чего я хочу достичь:
- поток Ulc1 прибывает первым: столбец «заблокирован» равен false, установите для него значение true и продолжите процесс обновления
- Поток Ulc2 прибывает, когда транзакция Ulc1 все еще находится в процессе, и хотя строка заблокирована с помощью функций innoDb, ему не нужно ждать, но на самом деле считывает «новое» значение заблокированного столбца, которое равно «true», и так на самом деле не нужно ждать, пока транзакция Ulc1 подтвердит чтение значения «заблокированного» столбца (в любом случае к этому времени значение этого столбца уже будет сброшено в false).

Я не очень разбираюсь в 2 типах механизмов блокировки, и я понимаю, что LOCK IN SHARE MODE позволяет другим транзакциям читать заблокированную строку, а FOR UPDATE даже не позволяет читать. Но это чтение получает обновленное значение? или 2-й прибывающий поток должен ждать, пока первый поток подтвердит, чтобы затем прочитать значение?

Любые рекомендации о том, какой механизм блокировки использовать для этого сценария, приветствуются.
Также, если есть лучший способ «проверить», не заблокирована ли строка (кроме использования флага столбца true / false), пожалуйста, дайте мне знать об этом.
благодарю вас

РЕШЕНИЕ
(Пример псевдокода 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);