bloqueo registros / formularios en app

[estrella_de_Galicia]

Llevo dándole vueltas a la cabeza y pese a que me han dado una solución, no me acaba de convencer.

Me explico:

Necesito evitar que dos usuarios o más puedan editar el mismo registro (NO ME SIRVE desde MySQL con el comando que existe)

Mi idea en un buen principio seria crear una tabla con el id de ususario, id de fila, la tabla y un campo de fecha y hora.

Asi si otro usuario quiere editar el registro le aparecerá un mensaje de "Registro bloqueado por el usuario XXXX".

Me comentan que esto traerá problemas y hace que tenga muchos accesos a la base de datos.

La alternativa que me han dado y NO me convence es que tan simple es que muestre un mensaje en pantalla de que hay un usuario el registro y con la posibilidad de poder editar los datos. Creo recordar que me dijo algo de usar sesiones de usuario o algo asi.

¿Quién me da un poco de luz para saber cual es la mejor forma de operar sabiendo que no quiero que se pueda editar el mismo registro desde dos usuarios distintos?

¿pros, contras?

[guardarmicorreo]

No entiendo por qué ofreces la posibilidad de editar un registro a un usuario que no quieres que lo edite. Simplemente no le ofrezcas el formulario y por si acaso, controla que quien envía la información está identificado como el usuario con permisos para editarlo.

[Eleazan]

Iniciado por guardarmicorreo

No entiendo por qué ofreces la posibilidad de editar un registro a un usuario que no quieres que lo edite. Simplemente no le ofrezcas el formulario y por si acaso, controla que quien envía la información está identificado como el usuario con permisos para editarlo.

El problema que tiene es de concurrencia, no de permisos.

Su caso es que tiene 2 usuarios que sí pueden editar el mismo registro. Y quiere evitar que lo registren "a la vez".

@estrella_de_Galicia

A bote pronto, guardas en sql / archivo / como quieras qué usuario está editando qué registro, y checkeas si alguien lo ha hecho antes que tu.

Y mientras alguien edita algo... que cada 10/15/30/60 segundos se lance una peticion ajax automáticamente para renovar ese "estoy editando". Asi sabes que si no se ha renovado en 10/15/30/60 segundos, que han cerrado el navegador / apagado el pc / lo q sea.

[guardarmicorreo]

Ah vale, pero entonces ¿eso no es un problema de autocommit y commit?

[estrella_de_Galicia]

Iniciado por guardarmicorreo

autocommit y commit?[/B]

¿Qué es eso?

Creo que si se tiene que hacer en Ajax, debería de ejecutarse cada 60 o 120, menos lo encuentro algo muy bestia, si hay 100 usuarios trabajando con la aplicación (y en diferentes registros)

[Eleazan]

Iniciado por estrella_de_Galicia

¿Qué es eso?

Creo que si se tiene que hacer en Ajax, debería de ejecutarse cada 60 o 120, menos lo encuentro algo muy bestia, si hay 100 usuarios trabajando con la aplicación (y en diferentes registros)

autocommit y commit es... para controlar si una query se ejecuta automáticamente, o sólo cuando se lo digas.

Se usa con las transacciones ;)

[guardarmicorreo]

En un principio, creo que hacer código para AJAX sin la garantía de que bloquee a un usuario si otro está realizando cambios es algo innecesario teniendo Commit de MYSQL (desconozco si existe en otras BD).

http://dev.mysql.com/doc/refman/5.0/es/commit.html

[Italico76]

No te sirve porque.... ?

Es mala idea con PHP hacer lo que le corresponde al motor de DDBB pero bueno...... lo puedes hacer es un rollback() para devolverte de una edicion si existe una previa:

http://www.php.net/manual/en/mysqli.rollback.php

[estrella_de_Galicia]

Como ya dije en 1er post, no quiero usar la instrucción de la base de datos

[Italico76]

Iniciado por guardarmicorreo

Ah vale, pero entonces ¿eso no es un problema de autocommit y commit?

No habia visto tu mensaje....pero si debe deshabilitar el 'autocommit'

[Eleazan]

Iniciado por guardarmicorreo

En un principio, creo que hacer código para AJAX sin la garantía de que bloquee a un usuario si otro está realizando cambios es algo innecesario teniendo Commit de MYSQL (desconozco si existe en otras BD).

http://dev.mysql.com/doc/refman/5.0/es/commit.html

En este caso, es un simple bloqueo de escritura de registro, no una "escritura controlada" como seria con el commit.

Commit, o transacciones, yo creo que las usaria en caso de tener que efectuar operaciones costosas, con consulta a varias tablas, y que poder volver atras en caso de necesitarlo.

O así lo veo yo, que puedo no ser correcto del todo

[Italico76]

Iniciado por Eleazan

autocommit y commit es... para controlar si una query se ejecuta automáticamente, o sólo cuando se lo digas.

Se usa con las transacciones ;)

EXACTO!, nuestro amigo @guardarmicorreo dio en el clavo pues el primer paso para hacer un rollback es deshabilitar el autocommit como dice el manual de PHP

http://www.php.net/manual/en/mysqli.rollback.php


De todas formas sigue siendo mejor bloquear el registro...y ya si @estrella_de_Galicia no quiere usar el motor de DDBB deberia explicar porque para poder ayudarle mejor.

[guardarmicorreo]

Tú tendrás tus motivos, razonados o no, para no utilizar algo que hará más efectivo la tarea que quieres realizar. De otra manera, puedes recurrir a AJAX como te han señalado antes, pero aun cuando establecieras una revisión del registro cada segundo, siguen habiendo décimas de segundo y centésimas de segundo, etc. Dos usuarios pueden coincidir en el mismo segundo.

Por eso la existencia de commit, que evita que por ejemplo, en una transacción bancaria, una persona realice un pago si otra está realizando una operación que puede que deje sin saldo a la otra persona. Esto es efectivo porque es la propia BD quien restringe la operación, volviéndola solo accesible por lectura, pero no para escritura, por ejemplo.

Además está la ventaja que descargas este trabajo en algo propio y natural de la BD en la propia BD, mientras que de la otra manera descargas el trabajo en el servidor y el cliente, haciendo tu aplicación más lenta y menos accesible, por cuestiones técnicas del usuario (no todos los navegadores soportan una gran carga de operaciones con javascript... mis navegadores sufren con feisbuk... :) ).

Así que, en un principio y desde un punto de vista eficiente e inteligente y una buena práctica, utilizar AJAX para simular algo que debe hacer la BD y sin lograr las garantías necesarias, es una idea no muy exitosa.

Ahora quedaría saber ¿por qué no quieres utilizar algo innato de la BD?

[estrella_de_Galicia]

Iniciado por estrella_de_Galicia

Como ya dije en 1er post, no quiero usar la instrucción de la base de datos

Creo que o no me expreso bien o se ha pasado por alto mi comentario

[estrella_de_Galicia]

Porque sino no hay forma de controlar que usuarios tienen bloqueados cuales registros por toda la aplicación.

Necesito de algún modo indicar al usuario que ya se está editando el registro antes de que pulse el botón editar. OJO cuando se pulsa en guardar, sino antes de mostrar en pantalla los campos editables

[guardarmicorreo]

Creo que te hemos leído, pero estaría bien saber el por qué. Respecto a una solución sin utilizar commit, pues las que tu imaginación te de, pero no podrás alcanzar las garantías que te da la propia BD.

Un saludo.

[guardarmicorreo]

Vale, tienes dos necesidades: bloqueo a nivel de usuario y bloqueo a nivel de BD.

¿Por qué no pones en una tabla temporal un registro de entradas que se están editando y si un registro que un usuario quiere editar aparece en esa tabla lanzas el mensaje de acceso denegado?

Y por otro lado puedes reforzar la aplicación con commit.

[estrella_de_Galicia]

El problema con commit es que NO puedo saber que usuario está bloqueando un registro ¿y si el usuario cierra el navegador? entonces ese registro quedará bloqueado ¿no?

[estrella_de_Galicia]

Mirando el tema del commit creo que no me hace falta. Puesto que los pasos que sigue mi aplicacion son:
1- listado de registros
2- selecciono el registro que quiero editar
3 abre el formulario de edición pero si esta en uso solo muestra el contenido del registro sin posibilidad de guardar datos, vamos, un simple select

Finalmente si he sido el primer usuario en editar el registro entonces y solo entonces ya me permite hacer el update a la base de datos

[Italico76]

Iniciado por estrella_de_Galicia

El problema con commit es que NO puedo saber que usuario está bloqueando un registro ¿y si el usuario cierra el navegador? entonces ese registro quedará bloqueado ¿no?

Ha leido algo del manual desde el otro post ?

http://dev.mysql.com/doc/refman/5.0/...ion-model.html
http://dev.mysql.com/doc/refman/5.0/es/lock-tables.html


Igualmente si Ud hace la simulacion de bloqueo con PHP si el usuario cierra el navegador Ud le puede dejar eso bloqueado indefinidamente sino establece una politica de desbloqueo por tiempo por ejemplo.

Segun lo que leo...... Ud podria usar UNLOCK pero la forma correcta seria hacer el COMMIT asi que si el usuario no presenta actividad digamos por 2 horas, Ud le hace el COMMIT a ese registro y con eso se termina la transaccion.

[guardarmicorreo]

Iniciado por estrella_de_Galicia

Mirando el tema del commit creo que no me hace falta. Puesto que los pasos que sigue mi aplicacion son:
1- listado de registros
2- selecciono el registro que quiero editar
3 abre el formulario de edición pero si esta en uso solo muestra el contenido del registro sin posibilidad de guardar datos, vamos, un simple select

Finalmente si he sido el primer usuario en editar el registro entonces y solo entonces ya me permite hacer el update a la base de datos

Si la aplicación solamente va a estar disponible por web no, commit no te hace falta, porque es la propia aplicación la que restringe el acceso a un registro en la BD utilizando MYSQL.

Si la aplicación estará disponible en otras plataformas, sí, commit te hará falta, porque habría otras aplicaciones gestionando el acceso a un registro en la BD, utilizando tal vez otras BD sin tener acceso a la tabla temporal u otros mecanismos de control de acceso.

Depende de cómo se platee la aplicación y cuanto quieres dejarla preparada para una extensión de la misma.

[estrella_de_Galicia]

La aplicacion solo va a estar disponible via web. Es cierto que para otros procesos que no bienen al caso necesitara aceso de lectura pero tan solo la aplicacion sera via web

[guardarmicorreo]

Bueno, intentalo con una tabla temporal entonces. Pero, si el bloqueo puede ser solamente en el momento de pulsar para la edición del registro mejor que mejor, de otra manera comenzarían las sobre cargas a la BD.