Estoy intentando evitar que un usuario se loguee más de una vez en la aplicación. Para ello cuando el usuario entra capturo su nombre (sysUserName) y lo guardo en una variable global en disco. Si ese usuario intenta acceder de nuevo, al ser su nombre igual al nombre guardado en la variable, fuerzo un Salir de la aplicación.
Al salir el usuario logueado por primera vez de la aplicación cambio el valor de la variable a blancos. Hasta aquí todo ok.
Problema en el que ando atascado desde hace días: Si el usuario sale da la aplicación por medios no convencionales (desconexión de internet, cuelgue, etc.) la variable queda guardada en disco con el nombre del usuario e impide el acceso a ese usuario en cualquier próxima conexión (problema grave).
¿Conoce alguien la manera de cambiar el valor de una variable condicionada a la existencia de enganche al servidor, tal vez con alguna función del API, o ha podido solucionar el problema del doble logueo de otra manera?.
Cordial saludo y gracias por vuestra atención. Daniel.
Ok Gracias. Lo miraré. Solo aclarar que el control lo intento hacer con una variable en vez de con una tabla ya que cada usuario tiene su carpeta de datos.
Es cierto que este tema tiene sus complicaciones y mientras no sea el vServer el que lo gestione estaremos siempre con chapucillas.
Por el lado del vAdmin tener un enganche activo no significa que haya un Usuario logueado en el vClient ya que hay un timeout de 300 segundos por defecto (es configurable) antes de que el vServer borre el enganche. Por lo tanto habría que esperar un mínimo de 5 minutos antes de considerar la conexión como perdida definitivamente y poder conectar nuevamente con el mismo Usuario.
Por el lado de vClient tenemos que diseñar alguna forma de saber si el Usuario está activo en la Aplicación y no se ha quedado colgado o cerrado bruscamente la aplicación.
Grabando un valor FIJO en una variable global de disco como ya has comprobado “no sirve”.
Tienes que grabar en la variable global en disco una “marca de tiempo” cada cierto tiempo para que el segundo intento de conexión sepa que hay actividad y no puede conectar.
Por lo tanto, tienes que habilitar un Timer (en un Dock de tu aplicación con un formulario nativo o mejor QML) que ejecute un proceso, por ejemplo cada minuto, que grabe en la variable global en disco una “marca de tiempo”.
Cuando el segundo usuario intenta conectar debe comprobar que NO existe una “marca de tiempo” reciente y de esta forma confirma que no hay actividad y puede conectar.
Por supuesto el tiempo mínimo entre conexiones deberá ser en este caso de 1 minuto.
Puedes usar también una tabla en lugar de la variable global en disco.
Tienes que afinar los detalles, pero básicamente el diseño consiste en que el segundo usuario sepa con certeza que el primer usuario está activo porque ha grabado recientemente una marca de tiempo.
Gracias Paco, efectivamente el tema es complejo. Y en mi opinión importante ya que los costes por usuario concurrente en despliegue son elevados. Un usuario que abre varias sesiones sale muy caro, ya que si no puedes limitarlo has de sobredimensionar el número de usuarios concurrentes…
Comenta “Solucionamos” que hay novedades respecto a este tema en la versión 24. He estado mirando y no encuentro informacion de esta nueva versión 24. ¿Hay alguna manera de acceder a ella?
Cordial saludo. Daniel.
De momento solo los usuarios certificados de Velneo tienen acceso a las novedades de la 24.
Tendrás que esperar al Seminario de presentación el 6 de noviembre.
En cualquier caso, puedes hacer pruebas con el método que te he propuesto.
Las novedades de la versión 24 nos habían creado una falsa expectativa al respecto (sobre todo el llamado “Control de reconexión y desconexión”):
Realmente, necesitamos es una función para pedirle al vServer en cualquier momento la “lista de conexiones que siguen activas” (o sea, la lista de Enganches que aparece en el vAdmin) o averiguar por el estado de conexión de un usuario específico.
Con las novedades de la versión 24, a lo sumo, podremos usar la función “Reconectar al servidor” del marco AUTOEXEC para realizar una actualización adicional de la “marca de tiempo” mencionada por Paco arriba.
