| Autor |
Mensaje |
infocaudete
|
# Publicado: 3 Feb 2011 12:56
Tengo 2 problemas que no se como solucionar definitivamente.
El primero es que cuando 2 usuarios acceden a una tabla uno de ellos queda bloqueado, pero la aplicación se para de tal manera que parece que se ha bloqueado ¿cómo podría avisar al segundo usuario que la tabla esta siendo usada? ¿cómo podría hacer que el bloqueo sea durante el menor tiempo posible?
El segundo es que cuando 2 usuarios crean un registro de tablas que tiene el indice autonumerico o que se generan automáticamente, en los 2 casos te da el mismo número, con lo que el segundo usuario tiene un error de código duplicado, ¿cuando debería realizar el calculo?
Saludos y gracias
|
Anónimo
|
# Publicado: 3 Feb 2011 16:05
Esto creo que te puede ayudar:
http://abanq.org/laboratorio/blog/index.php?p=21
Un saludo
|
infocaudete
|
# Publicado: 4 Feb 2011 12:43
Esto lo he visto, gracias, pero no se realmente donde tengo que aplicarlo. Por ejemplo si esto pasa en contactos en que commit tendría que ponerlo para que me avise.
Gracias.
|
yopli2k
Miembro |
# Publicado: 4 Feb 2011 18:18
Hola, para mí este es uno de los temas más calientes de esta aplicación. El sistema de bloqueo que se puso, tiene un principal inconveniente, que el control se hace cuando se graba por lo que no sirve de mucho que te diga que el usuario "x" tiene bloqueado el registro "n" y tengas que cancelar todo el trabajo para que el otro usuario termine, aunque es mejor a que se quede colgado. Además muchas veces le sale el mensaje a un usuario que está bloqueado y al otro que también le bloquea el usuario anterior por lo que al final acabas cancelando en los dos terminales los procesos para evitar problemas con el stock.
Otro problema que me he encontrado a menudo es que estás editando unos datos que no tiene nada que ver con los del otro usuario y terminan saliendo mensajes de bloqueo. Haces un seguimiento a los id de registros que te dice pero no tienen sentido pues tu estás en la tabla de formas de pago y te dice que estás bloqueando registros de stock.
Quiero decir que me gusta mucho la aplicación y que se ha hecho y se está haciendo un gran trabajo, pero como en todas las aplicaciones hay cosas buenas y otras no tanto.
|
infocaudete
|
# Publicado: 5 Feb 2011 15:09
¿Entonces que propones? Porque de alguna manera se podrá arreglar digo yo.
|
yopli2k
Miembro |
# Publicado: 9 Feb 2011 10:22
Reconozco que llevo un tiempo pensando y haciendo pruebas pero es un tema complicado puesto que está muy metido en la filosofía del programa. Las transacciones se abren nada más abrir un formRecord y los bloqueos se mantienen durante todo el tiempo hasta que se cierra el formulario.
Además mis conocimientos de C son muy básicos por lo que tampoco me puedo plantear modificar el fuente. Pero me ofrezco en la medida que puedo a ayudar en una posible solución.
Repito que me gusta mucho la aplicación, y siempre habrá aspectos a mejorar.
|
infocaudete
|
# Publicado: 15 Feb 2011 17:44
En algunos apartados esta solucionado, supongo que son los más conflictivos (facturas, crm...) pero a mi los bloqueos se daban al acceder dentro de esos a otras tablas.
La solución que se ha dado en eso areas son crear una tabla de secuencias que se incrementan con cada nuevo registro de manera que no tienes que bloquear la tabla más que un instante, cuando vas ha grabar(esa es la idea).
Voy a aplicar este mismo concepto en el resto de sitios que a mi parecer producen bloqueos y espero que así se vaya solucionando el tema.
El indice autonumérico también tiene solución y pasa por comprobar el último numero solo cuando se haya aceptado el formulario de registro, es decir en acceptedform.
Espero que esto os sirva también como posibles soluciones.
|
Anónimo
|
# Publicado: 21 Feb 2011 21:45
Sobre la concurrencia y bloqueos hay escritos libros y libros y no es una cosa trivial, tampoco existe la solución perfecta, como muchas cosas en informática hay dos variables opuestas e inversamente proporcionales y nadie lo puede evitar; son el numero de bloqueos y el riesgo a perder datos, podrás reducir el numero de bloqueos pero arriesgandote a perder la consistencia de los datos y viceversa podras asegurar al 100% la consistencia de los datos pero aumentarán inevitablemente el numero de bloqueos, cualquier experto en base de datos sabe que eso es así, por lo menos hasta que los ordenadores cuánticos sean una realidad y se pueda estar simultáneamente en varios estados.
Abanq en esto es muy conservador, tal vez demasiado para mi gusto, prefiere bloquear a la mas mínima antes que caer en un estado inconsistente. Pero esto se debería poder configurar, desconozco si haría falta tocar algo del código fuente, es probable que si, pero tiene que ver mas con la base de datos que con Abanq, por ejemplo en Postgresql se puede elegir un nivel de aislamiento de transacción "mas audaz", en este enlace explica como:
http://www.postgresql.org/docs/8.3/static/transact ion-iso.html
Si veis ese enlace, en la tabla de niveles de aislamientos, se ve claramente lo de la relacion inversa bloqueos/consistencia, conforme disminuyes el nivel de aislamiento de la transacción son mas posibles los riesgos de lecturas sucias, fantasmas o repetidas, y conforme lo aumentas desaparecen esos riesgos.
Elige el riesgo que quieres asumir, lo configuras con SET ISOLATION LEVEL, y suerte.
Tambien hay otros rodeos y truquillos como dice infocaudete, pero tarde o temprano siempre caes en el dilema de bloquear o perder consistencia.
Un saludo.
|
