Sistema de bloqueos
Velneo vServer dispone de un sistema de bloqueos de ficha muy depurado, lo que evitará al programador definir nivel de aislamiento alguno.
En formularios, por defecto, existe lo que llamamos bloqueo blando, es decir, si dos usuarios editan la misma ficha, modifican y aceptan cambios, si no hay colisión (es decir, si han modificado campos diferentes) se funden las modificaciones de ambos. Si hay colisión, es decir, que modifican un mismo campo, el valor que mantenga la ficha en ese campo será el del usuario haya guardado la ficha en primer lugar.
En procesos, actualizaciones, etc. se produce un bloqueo duro, es decir, si una ficha está bloqueada no se podrá tener acceso a ella en modo escritura, pero sí en modo lectura. Una vez haya finalizado el bloqueo, ya podrá ser bloqueada de nuevo en modo lectura/escritura. Si dos usuarios lanzan un proceso transaccional que en un punto colisiona -los dos intentan modificar el mismo registro- el programa dejará a la espera una de las transacciones y reintentará unas cuantas veces, si no logra continuar, la deshará y avisará al usuario.
En formularios también es posible definir que realicen un bloqueo duro. Se trata de una propiedad del objeto formulario que, en caso de activar, bloqueará el registro que sea editado en ese formulario, provocando el inicio de una transacción y lo bloqueará en exclusiva en modo lectura/escritura hasta que finalice la transacción. Eso tiene varias implicaciones:
Dado que la edición de la ficha implica el inicio de una transacción todas las operaciones de lectura/escritura que derivadas de la edición de ese registro (actualizaciones, modificación de históricos desde una rejilla incluida como control objeto del formulario, etc.) quedarán englobadas en la misma, por lo que si la transacción es deshecha, se desharán todas las operaciones de escritura realizadas tanto directa como indirectamente desde ese formulario.
Todas las fichas modificadas directa o indirectamente desde el formulario serán también bloqueadas, por lo que tampoco podrán ser modificadas por otros usuarios o proceso. Esto es algo que debemos tener muy en cuenta a la hora de decidir si realizar un bloqueo duro no en un formulario.
Mientras el formulario permanezca abierto la ficha podrá ser leída por otros usuarios desde otros formularios que no tengan activado el estilo bloqueo duro o desde otros procesos, pero no podrá ser modificada; Al contrario de lo que sucede en el bloqueo blando, en el que dos usuarios pueden editar un mismo registro mientras los campos que modifiquen sean distintos.
Mientras el formulario permanezca abierto, si otro usuario intenta editar esa misma ficha con un formulario que tenga activado el estilo bloqueo duro, no podrá editarla ya su apertura iniciará la transacción para bloquearlo, pero, como ya se encuentra bloqueado, no podrá continuar con la transacción.
Si usamos un formulario con bloqueo duro como dock el registro editado en el mismo permanecerá bloqueado todo el tiempo ya que, aunque se cierre el dock, el formulario sigue abierto pues cuando cerramos un dock no cerramos el objeto contenido en él sino que lo ocultamos
En ese tipo de formularios, para cancelar la modificación dispondremos de dos comandos de botón: cancelar/cancelar controlado: si usamos este comando se cancelarán solamente las modificaciones realizadas en la ficha editada y no aseguradas en disco. Las modificaciones realizadas en otras fichas, en plurales o registros maestros actualizados por ejemplo, no serán deshechas, salvo, claro está, aquellas actualizaciones en las que intervenga el campo o campos cuya modificación será cancelada.
Deshacer/Deshacer controlado: si usamos este comando se deshará la transacción, es decir, que se desharán todas las operaciones de escritura realizadas tanto directa como indirectamente desde ese formulario. Este comando equivale al comando de instrucción de proceso deshacer transacción.
Última actualización 2yr ago