LOCK IN SHARE MODE permitirá que el segundo subproceso lea el valor, pero el valor real será el anterior a la consulta (lectura confirmada) o antes de que se haya iniciado la transacción (lectura repetible) (ya que MySQL usa versiones múltiples; y qué tienen que ser vistos por la segunda transacción se define por el nivel de aislamiento). Entonces, si la primera transacción no se confirma en el momento de la lectura, se leerá el valor anterior.
En su escenario, es mejor tener 1 transacción que bloquee el registro con seleccionar para actualizar, otra que funcione en el registro y al confirmar/deshacer, la tercera desbloquea el registro.
La transacción del segundo subproceso con seleccionar para actualizar esperará a que se complete la primera, luego leerá el valor real y decidirá no continuar con las otras transacciones, pero informará al usuario que el registro está bloqueado.
Para evitar un punto muerto, asegúrese de hacer select for update usando un índice único.
Código de ejemplo:
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);
