Fijarse si alguien esta modificando el registro al que quiero entrar

[gabriel em]

Hola amigos de foro!!
Tengo una pagina donde pueden entrar varios usuarios a la vez y estos pueden modificar cosas, el problema que tengo es el siguiente:

Tengo un campo que se llama "slogan" y los usuarios pueden entrar y modificarlo. El problema que se me ocurre es cuando un usuario entre a modificarlo y justo mientras lo esta modificando, entre otro usuario de otra maquina y tambien entre a modificarlo.

Entonces lo que voy a hacer es que cuando alguien entre a modificarlo una variable "SloganEnUso" se ponga True y no deje que los demas entren hasta que este salga y "SloganEnUso" se ponga nuevamente en False.
Hasta ahi todo bien, ahora se me ocurre este problema que no se como solucionar:

Entra un usuario a modificar el slogan, entonces "SloganEnUso" se pone true. Entonces otro usario de otra maquina quiere entrar a modificarlo, pero como "SloganEnUso" es True le dice que no puede entrar porque esta en uso.
Justo en ese momento el primer usuario se distrae y se va a pasear el perro. El otro se queda 20 minutos sin poder entrar a modificar el slogan !

Como lo puedo solucionar? se me ocurre con session time out pero no se como..

[Shiryu_Libra]

y lo que quieres es que si Usuario1 no ha dejado de modificarlo negarlo hasta que el suelte el registro??, bueno creo que optaste por tenerlo en session, pero debemos recordar que si un usuario se le asignan valores a su SESSION, estos datos desaparecen al termino del tiempo de session o cuando el usuario sale... pero en APPLICATION, los datos se quedan para todos los usuarios dentro del sitio... no se si me explico???

en ves de asignar que ese valor esta ocupado en session, asignarlo a una variable application

<%
Application.Lock
Application("SloganEnUso")=true
Application.Unlock
%>

y de esta manera si tu usuario entra a modificar algo, todos los demas usuarios que entren seran notificados de que se esta modificando en ese momento y que esperen a que lo "suelten"

una idea
suerte

[gabriel em]

Shiryu gracias por tu solucion. Es la que voy a utilizar, pero como dije antes:
y si el usuario1 entra a modificar el slogan y por otra causa se distrae y se va y deja la computadora sola? El usuario2 nunca va a poder entrar.
Por eso yo pensaba hacer algo asi pero no se como :

Código:

<%
Application.Lock
Application("SloganEnUso")=true
--> Application("SloganEnUso") = ***que dure 5 minutos y despues se ponga en False***
Application.Unlock
%>

Asi le doy 5 minutos para hace el cambio, que es mas que suficiente. Pasa que no se que funcion cumple con lo que estoy buscando si es que hay una, sino voy a tener que usar otra variable que lleve el tiempo.

[sjam7]

y con una cookie que dure esos 5 minutos?

[Shiryu_Libra]

Slam7

es que precisamente es eso, si usamos cookies o variables session, estas solo ocurren para el usuario X, pero si el Usuario Y pretende modificar, lo hara sin restricciones, entonces por eso mismo, estamos tratando de implementar en variables de Application, por que asi es mas facil que los usuarios se les pueda restringir el uso a esa entrada "SloganEnUso"

pero viendo como pretendes usar esa misma???

por otra parte retomando lo que menciono Gabriel_EM, lo que se puede implementar es una Cuenta Regresiva, logicamente en javascript, que por ejemplo a 5 minutos de inactividad o 10, lo que ocupas y mediante una simple instruccion de AJAX, donde una pagina resetear.asp, elimina esa variable para poder modificar nuevamente

suerte

[CésarBalaguer]

Eso se resuelve con transacciones en la base de datos.

El motor de la base de datos controla los bloqueos y accesos a la informaciòn cuando alguien esta actualizando la data, genera una cola de espera hasta que un usuario termine de actualizar la informaciòn, una vez realizado eso entra el otro usuario y los que vienen detras quedan en espera.

no te recomiendo usar ese tipo de bloqueos con variables o usando tiempos dado a que puedes encontrarte con usuarios lentos o simplemente con conexiones lentas por lo que no te garantiza nada que pasados los 5 minutos o los x minutos se haya terminado de actualizar la data.

el modo de empleo de las transacciones es:

conexion.BeginTrans
conexion.Execute sSql '*** actualizaciòn ***'
'*** si no hubo error...
conexion.commitTrans
'*** si hubo error...
conexion.rollbackTrans
'****

Lo màs recomentable es dejar que el motor de la base de datos haga su trabajo dado a que no es ùnicamente almacenar informaciòn.

[Shiryu_Libra]

buena implementacion Cesar y sobretodo con lo que mencionas de usuarios lentos y uno que otro perezoso

[sjam7]

excelente, y esto es para todas las bases de datos? o es particular de cada una?

[Shiryu_Libra]

de hecho lo que menciona Cesar(), ataca directamente la conexion abierta

[CésarBalaguer]

Es cierto que ataca a la conexiòn abierta en ese sintante, sin embargo el Access hasta la versiòn 2000 no aceptaba los comandos de transacciòn, he probado con sqlserver, sybase y db2; y en todas a funcionado perfectamente.

[edu007ar]

hola... no sé si estaré equivocado, pero me parece que el tema de las transacciones bloquea el acceso a un registro pero solo al momento de acceder a él...

y lo que creo que gabriel_em necesita es que el registro esté bloqueado mientras el usuario piensa y edita en una página web el contenido, por lo cual los únicos momentos en los que se accede al registro es antes de la edición para poder ver el contenido y después para actualizarlo.... pero el bloqueo debe estar desde el principio hasta el final, incluyendo el tiempo que se tarda en pensar y escribir...

la solución que se me ocurre sería grabar alguna variable global con el valor de timer() y el usuario que está adentro, si alguien más intenta acceder compara el timer() actual y le resta el timer() grabado en la variable, si supera los 300seg (=5 min) es porque está liberado o fuera del tiempo permitido.....

Slds..

[CésarBalaguer]

Es cierto que la transacciòn bloquea el registro al momento de acceder a el, siempre y cuando la transacciòn haya sido creada en una actualizaciòn de data.

Si lo que quiere es bloquear la pàgina mientras el usuario este pensando, entonces la transacciòn no le va a servir (almenos no para ese fin, sin embargo si debe incluirla para su actualizaciòn).

Otra forma ademàs de la variable global que puede usar, es una columna en la tabla que le indique si el registro esta o no siendo actualizado, y asì el usuario se puede tomar todo el tiempo que requiera para pensar.

Particularmente no soy muy amigo de los bloqueos mientras el usuario piensa porque hacen mas lento un sistema, prefiero manejar eso ùnicamente en el momento de la actualizaciòn de data, de esa manera puedo controlar la integridad de informaciòn y a la vez hacer un sistema àgil.

Saludos.

[u_goldman]

Iniciado por CésarBalaguer

Particularmente no soy muy amigo de los bloqueos mientras el usuario piensa porque hacen mas lento un sistema, prefiero manejar eso ùnicamente en el momento de la actualizaciòn de data, de esa manera puedo controlar la integridad de informaciòn y a la vez hacer un sistema àgil.

Y tienes toda la razón, realmente desarrollar una aplicación con un sistema de bloqueos temporal costará mucho trabajo y dependerá de muchas cosas, al final creo que estarás construyendo una aplicación muy problemática.

Podrías crear sin embargo, algo más sofisticado y seguro, pero requeriría de un ciclo de aprobación de al menos dos pasos, uno de edición, que es cuando el identificador del item en curso se va a la tabla de bloqueos, si dicho item está en la tabla de bloqueos, no podrá ser editado o aprobado, y el otro el paso de aprobación, que como su nombre lo indica te pemitirá aprobar el item en cuestión, aunque esto te lleva inevitablemente a trabajar con usuarios, permisos, etc. haciendo mucho más complejo tu sistema.

Saludos

[Shiryu_Libra]

por eso al principio del POST, era mas sencillo, o implementar un campo donde se restringe la edicion mientras un usuario, o una varible tipo Application, para evitar siquiera intentar entrar a modificar "el" registro en cuestion

[u_goldman]

Iniciado por Shiryu_Libra

por eso al principio del POST, era mas sencillo, o implementar un campo donde se restringe la edicion mientras un usuario, o una varible tipo Application, para evitar siquiera intentar entrar a modificar "el" registro en cuestion

No, no es nada mas eso...tienes que pensar en muchas mas opciones, si haces un campo tal cual, no tienes manera de saber si se deja en modo edición, quién lo dejó, en qué fecha, etc...no es lo mismo

[Shiryu_Libra]

y aki es donde defiendo mi tesis nuevamente,

es que el campo actuaria como control donde nosotros insertaramos el usuario, fecha y una variable 1/0... por ejemplo

1=en uso.... 0=que sera???
separados por ","
despues agregamos una variable... que se les antoja, el index del usuario, para que no haya errores????
y nuevamente ","
una fecha para no andar con Psych?... y dejamos que el SQL nos diga en que fecha de modificacion se llevo a cabo
bueno resumiendo las palabrerias nos quedaria un campo de esta indole

si no esta modificado
0,12,20070622,13:00:22
o si esta en modificacion
1,12,20070622,13:05:27

bueno, se que no es correcto, pero como solucion practica para evitar problemas mientras se desarrolla algo en serio y con buena practica, saca del apuro.... no creen?

otra idea

:r isa:

suerte

[u_goldman]

Iniciado por Shiryu_Libra

y aki es donde defiendo mi tesis nuevamente,

es que el campo actuaria como control donde nosotros insertaramos el usuario, fecha y una variable 1/0... por ejemplo

1=en uso.... 0=que sera???
separados por ","
despues agregamos una variable... que se les antoja, el index del usuario, para que no haya errores????
y nuevamente ","
una fecha para no andar con Psych?... y dejamos que el SQL nos diga en que fecha de modificacion se llevo a cabo
bueno resumiendo las palabrerias nos quedaria un campo de esta indole

si no esta modificado
0,12,20070622,13:00:22
o si esta en modificacion
1,12,20070622,13:05:27

bueno, se que no es correcto, pero como solucion practica para evitar problemas mientras se desarrolla algo en serio y con buena practica, saca del apuro.... no creen?

otra idea

:r isa:

suerte

Santo Dios, almacenando variables escalares en un solo campo, con eso tenías para reprobar normalización de bases de datos.

Y no, no es práctico para nada, por favor niños, no imiten eso...

Saludos

[Developer9]

Yo de moredador lo baneo por dar mal ejemplo

[CésarBalaguer]

no creo que la solución vaya por ese lado.
Más me inclino a usar transacciones de base de datos y olvidarme de bloquear la página de edición del registro.

En todo caso, de ser muy necesario, o mejor dicho impresindible, otra forma es aperturar la transacción antes de mostrar la información en pantalla, hacer una actualización ficticia a la base de datos para bloquear el registro solicitado, recuperar la información, mostrarla y que el resto de usuarios espere hasta que al usuario que tiene el bloqueo se le ocurra cerrar la transacción, de esa manera estoy bloqueando desde que muestro la información y no únicamente la actualización de la data; pero definitivamente, no es óptimo ni recomendable bloquear la edición.

Quizá Gabriel nos pueda explicar cual sería el fin de bloquear el registro desde su edición.

[Shiryu_Libra]

Iniciado por u_goldman

......

Y no, no es práctico para nada, por favor niños, no imiten eso...

....

jajajjajajja

pero ya hablando en serio, y obviando el escrito anterior, que era solamente en plan de mofarnos un rato y HACIENDO ENFASIS A LO QUE DIJO U_G

¡¡¡¡NO IMITEN ESO!!!


que solucion sencilla y sin tanto show se puede implementar?

[tammander]

Iniciado por gabriel em

Hola amigos de foro!!
Tengo una pagina donde pueden entrar varios usuarios a la vez y estos pueden modificar cosas, el problema que tengo es el siguiente:

Tengo un campo que se llama "slogan" y los usuarios pueden entrar y modificarlo. El problema que se me ocurre es cuando un usuario entre a modificarlo y justo mientras lo esta modificando, entre otro usuario de otra maquina y tambien entre a modificarlo.

Entonces lo que voy a hacer es que cuando alguien entre a modificarlo una variable "SloganEnUso" se ponga True y no deje que los demas entren hasta que este salga y "SloganEnUso" se ponga nuevamente en False.
Hasta ahi todo bien, ahora se me ocurre este problema que no se como solucionar:

Entra un usuario a modificar el slogan, entonces "SloganEnUso" se pone true. Entonces otro usario de otra maquina quiere entrar a modificarlo, pero como "SloganEnUso" es True le dice que no puede entrar porque esta en uso.
Justo en ese momento el primer usuario se distrae y se va a pasear el perro. El otro se queda 20 minutos sin poder entrar a modificar el slogan !

Como lo puedo solucionar? se me ocurre con session time out pero no se como..

Aparte de todo lo que se ha dicho, el bloqueo de registro es tarea del motor de la BD. ¿Tu crees que ese campo va a cambiarse tan a menudo? Te recomiendo que hagas un buen estudio preliminar de las necesidades del cliente y, si puedes, mejorarlas. El que dos o más usuarios manipulen un dato de la BD a la vez es muy improbable pero puede pasar. Este es un tema que lleva asi desde que se crearon las BD. Para eso estan los bloqueos.

Pero en la programación web las acciones sobre los datos de la BD se realizan de forma no persistente. Es decir, el usuario puede ver, manipular, modificar, borrar los datos en el navegador pero hasta que no se pulsa en botón de enviar (o hacer el postback, como mejor te plazca llamarlo) y dichos datos viajan con el documento HTML hasta el servidor, la BD esta liberada de toda conexion (no persistente). Que dos páginas web ataquen el mismo registro al mismo tiempo es aún más improbable. En caso de que esto ocurriera, obviamente se grabaría el que primero llegara. Esto es inevitable.

Tambien puedes crear un log en una tabla de todos los accesos al registro del slogan donde guardes quien lo hace, a que hora y dia y lo que queria guardar. Asi siempre puedes controlar todo lo que pasa en ese registro.

De todas formas, esta discusión es eterna. Que dos usuarios accedan al mismo registro al mismo tiempo en una conexion contra una BD no persistente es tan improbable como que un avión te caiga en la cabeza (improbable que no imposible )


Un saludo

[CésarBalaguer]

Indistintamente si cambie a menudo o no, basta con que cambie una vez para que se requiera utilizar un bloqueo exclusivo.

[lpz]

Hola.
Yo tuve un problema similar pero no logre soluccionarlo del todo todavia. Para prevenir que un usuario modifique un texto que esta siendo editado por otro usuario lo que hice fue lo siguiente: crear un array y ponerlo en un objeto application. Cada posicion representa al id de la pagina a modificar y el valor de cada elemento contiene al usuario que esta editando la pagina. Para saber si el usuario esta editando o no, me baso en los valores de variables del querystring. Una vez que termina de editar, setea el valor del array en esa posicion en vacio. Si se hace click en otro lugar y se esta en modo edicion (chequeo por variables de la url), setea todos los elementos del array que contengan el usuario actual a vacio.

El problema ahora es cuando el usuario cierra la ventana, quedan los valores seteados y quedan las paginas bloqueadas. Lo que intente fue setear a vacio los elementos correspondientes en el evento Sub Session_OnEnd, pero no esta funcionando.. incluso tambien intente eliminarlo, pero tampoco funciona (igual no serviria ya que puede que haya otros usuarios editando)

Alguna idea?