Cita: Eso es un problema de PHP, o de concepto?
Un error de concepto. Ya me ha quedado claro.
Cita: Por qué se presupone que por web, una persona abre para editar un registro a las 10 de la mañana, y guarda a las 5....Y eso es imposible que pase en una aplicación de escritorio?
Eso puede pasar tanto en una aplicación web como de escritorio. La diferencia está en que en web las conexiones no son persistentes como en una aplicación de escritorio y una transacción que leyera el registro con bloqueo no tendría sentido porque se cerraria en el momento que se enviara la respuesta al cliente.
Cita: Y si alguien tiene una modificación urgente que hacer?Es más feliz, y piensa que el sistema está mejor diseñado, porque al menos "sabe" que alguien tiene el registro bloqueado desde hace 7 horas?
Eso a mi me ha ocurrido como usuario, tanto con programas comerciales como no comerciales. Y por supuesto que me encontraba un registro bloqueado durante horas si el que lo estaba editando se había ido a tomar café o estaba de palique con la amiga o el amigo de turno. Hablo de aplicaciones cliente servidor pero en escritorio, no en web.
Código:
Y, para colmo, cuando llegan las cinco, le da a "cancelar" en el formulario, y ha mantenido el registro bloqueado durante 7 horas, para nada.
Así es. Lo he sufrido como usuario. Con sistemas de contabilidad en COBOL, después en ORACLE y después en SAMP.
Cita: Bloquear un registro antes de que exista una acción concreta a realizar sobre él, es algo que está intrinsecamente mal diseñado.
Desde el momento en que editas un registro ya estás haciendo una acción concreta sobre él. Editar un registro es hacer una lectura y una escritura. Lógicamente el bloqueo se ha de hacer en la lectura.
Cita: Presunción incorrecta:
Por? Si eso fuera así, no existirían problemas de concurrencia.
Exacto. Y es lo que buscamos, que no haya problemas de concurrencia.