|
A ver si me explico mejor:
Parte de lo que dice, Mick, lo entiendo perdectamente ya que si la segunda transacción no bloquea de forma pesimista con un lock, select for update o update inutil el registro,es normal que la primera transacción puede acceder al registro, modificarlo, comiterarlo y no encontrar problema alguno, luego la segunda transacción cuando quiera modificar (update) el mismo registro ya no actuará concurrentemente con la primera transacción que ya terminó.
Peró insisto que en este punto hay un problema. Según lo que creo haber entendido en "la cara oculta de C++" del señor Marteens, la modificación del registro realizada por la segunda transacción, si se realiza utilizando en la clausula WHERE todos los campos posibles de modificar (no solo la clave primaria, aunque en algunos casos esta tambien pueda cambiarse) resulta que la ejecución de la sentencia ModifySQL intenta un update sobre un registro que no encuentra, por lo que no puede realizar tal modificación, ahí es donde esta la anomalia.
Lanzando dicha sentencia SQL (update ....where ...) desde una utilidad SQL aparte se puede comprobar que la sentencia no afecta a ningun registro y devuelve:
This command did not return data, and it did not return any rows
mientras que si existiera el registro se obtendría:
1 Row(s) affected
YO ME PREGUNTO, ¿no es importante saber si realmente has podido realizar el update o no? los componentes IBX no informan de ninguna forma que la sentencia ha fallado, es decir no ha afectado a ninguna fila???
¿Me estoy equibocando en algo?¿la situación que planteo no es lo más normal si no se usan bloqueos pesimistas? de hecho el bloqueo optimista no se basa en esto: que todo el mundo pueda ir modificandolo todo hasta que salte un problema de este tipo?
Otra vez, gracias por la atención.
|