Ver Mensaje Individual
  #9 (permalink)  
Antiguo 04/12/2013, 12:24
Avatar de gnzsoloyo
gnzsoloyo
Moderador criollo
 
Fecha de Ingreso: noviembre-2007
Ubicación: Actualmente en Buenos Aires (el enemigo ancestral)
Mensajes: 23.324
Antigüedad: 16 años, 5 meses
Puntos: 2658
Respuesta: bloqueo de registros para manejar concurrencia

Cita:
creo que debo investigar un poco mas sobre las variables de usuario de mysql, y los bloqueos compartidos, creo q esa es la solucion a mi problema, voy a seguir investigando.. por ultimo .. sera que puedo capturar la variable de usuario actual de mysql? como para que ese registro del cliente que estoy trayendo con la consulta, solo me lo muestre a ese usuario conectado a la base. gracias.
No.
Vamos a ver si se entiende mejor así:

Cuando te conectas a una base de datos (cualquiera sea el DBMS), la conexión crea un espacio reservado de memoria donde existen y ocurren las acciones de ese usuario, y en ese espacio de memoria es donde existen las variables de usuario. Fuera de ese espacio, esas variables no existen.
Las bases de datos están diseñadas de modo tal que un mismo usuario podría abrir N sesiones distintas al mismo tiempo. Per cada una de esas sesiones es un bloque de memoria independiente, y no comparte nada con el resto de las sesiones abiertas. NADA. Las variables tampoco.
¿Qué implica esto?
Que tu puedes crear la variable "@a1" en cada una de esas N sesiones y darle diferentes valores dentro de cada una de ellas, y no se generan conflictos, poque cada una de ellas sólo existe en ese espacio o entorno.
La consecuencia en cuanto a "ver" las variables es más simple: Sólo pueden verse en una sesión las variables de usuario que fueron creadas en esa sesión y nada más.
¿Qué resulta de esto? Que no puedes usarlas para transferir el estado de lectura de un registro entre diferntes sesiones de usuarios, porque ellos jamás la verán en su sesión.

En otras palabras, las variables de usuario no sirven para tu caso.

¿Quieres una solución mas o menos sencilla?

Tienes dos opciones:
1) Agregar un campo a la tabla donde indiques el estado de reservado de ese registro, y que la consulta sólo pueda ver aquellos sin marca. Es algo complejo, pero funciona cuando está bien realizado.

2) Antes de guardar cualquier modificación que se haga sobre el registro leído, se debe realizar una revalidación del registro leído y asegurarse que los valores son los mismos que se leyeron. ¿Implica esto mucho más trabajo? Si, por supuesto, pero por increíble que te pueda parecer, esa es la forma elegida en todos los sistemas complejos que puedas maginar: Compañías de electricidad, bancos, telefónicas, seguros, etc.
¿por qué volver a validar todo lo ya validado?
Porque la información debe ser segura, aunque eso implique pérdida de performance.

En otras palabras: No busques una vía simple, fácil de programar y sencilla de verificar. Eso no existe.
__________________
¿A quién le enseñan sus aciertos?, si yo aprendo de mis errores constantemente...
"El problema es la interfase silla-teclado." (Gillermo Luque)