FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Averiguar conflicto por bloqueo
Hola a todos!
Tengo una base de datos Firebird a la cual se conectan varias aplicaciones 'diferentes' de forma concurrente. Ultimamente estoy teniendo problemas con bloqueo de registros y no se cual de las aplicaciones es la que esta generando el problema. Seguramente una de ellas en algun momento no cierra la transaccion y genera que el resto comiencen a fallar. ¿Hay algun forma de saber que aplicación tiene la transaccion activa? Tambien tengo mis dudas si es que algun usuario se ha conectado a la base de datos y sin querer esta provoncando el conflicto, ya que esto lleva tiempo funcionando y ha sido hace poco que da este problema. Saludos!
__________________
Saludos, Bitman |
#2
|
||||
|
||||
Hola Toni.
Fijate si te resulta útil: How to detect applications and users that hold transactions open too long? Saludos
__________________
Daniel Didriksen Guía de estilo - Uso de las etiquetas - La otra guía de estilo .... |
#3
|
|||
|
|||
Si, precisamente lo estaba probando.. pero veo que no me salen todas las conexiones.. Y todo son aplicaciones propias, que habren la conexión a la base de datos al inicio de la misma. Voy a seguir mirando..
Probare en la instalación que hay el problema a ver si veo algo concreto. Gracias por la respuesta!
__________________
Saludos, Bitman |
#4
|
|||
|
|||
Son interesantes estas tablas para el monitoreo de la base de datos, por el momento no he conseguido averiguar con esto de donde viene el problema. He visto incluso que hay una tabla para ver las ultimas sentencias SQL que se han ejecutado, pero en la practica no veo nada..
Se os ocurre alguna idea para poder localizar este tipo de fallo? Por el momento yo no puedo ni reproducirlo, pero al cliente si le sale. Como es una instalación que trabajan unos 8 usuarios concurrentes pues claro no es facil reproducirlo en diseño.
__________________
Saludos, Bitman |
#5
|
||||
|
||||
Que te digan exactamente en qué pantalla ocurrió y qué estaban haciendo.
|
#6
|
|||
|
|||
Hola Casimiro, si ya voy haciendo ese seguimiento. Pero hay usuarios que estan en administracion otros en produccion, almacén.. Ya les he comentado que me avisen cuando se quedan 'clavados'. Pero seguramente la accion que provoca todo la realiza un usuario que ni se entera y les provoca el fallo a los otros.
El dato que si se es mensaje que da de "lock conflict" con una tabla de stocks que realizan operaciones sobre ellas muchos procesos.
__________________
Saludos, Bitman |
#7
|
||||
|
||||
Pero, ¿qué error es el que muestra?
|
#8
|
|||
|
|||
Pues hay dos mensajes:
1.- lock conflict on no wait transaction. deadlock. update conflicts with concurrent update, at procedure 'PPPPPPPPP' 2.- lock conflict on no wait transaction. at trigger 'TTTTTTTT', at procedure 'PPPPPPPPP' Es una aplicacion que tiene sus años, y esto a aparecido en la ultima actualizacion. Pero claro hay tantas variaciones que vete a saber.. Sospecho que sera alguna transaccion que la he sobrecargado y tardo mas tiempo en confirmarla y esto da pie a un conflicto.
__________________
Saludos, Bitman |
#9
|
||||
|
||||
Bien, entonces parece que ahí tienes los problemas.
|
#10
|
||||
|
||||
Cita:
Mira en que ventanas se bloque y con que tabla específicamente y busca donde se puede dar transacciones que puedan durar segundos o minutos, fácilmente ahí vas a encontrar el problema
__________________
"Como pasa el tiempo..... ayer se escribe sin H y hoy con H" |
#11
|
||||
|
||||
Eso no debe suceder si la transacción está configurada así:
Código:
read_committed rec_version nowait |
#12
|
|||
|
|||
Pues asi las tengo configuradas Casimiro. Respecto a lo que dice RONPABLO, a mi no me ocurre en esas situaciones porque trabajo con clientdataset's y es este el que enlazo contra los componentes visuales. Y ya intento en todas la aplicacion que las transacciones sean los mas cortas posibles y no dependan del usuario.
Aun con esto al tratarse de una aplicación multi-usuario que trabajan en tiempo real, cualquier detalle puede causar un problema por la concurrencia. Sobretodo en el acceso a tablas comunes. Evidentemente es que hay algun problema de diseño en el programa. Aunque no se si con algun otro tipo de configuracion de Firebird podria ser mas tolerante a este tipo 'fallos'. Por ejemplo en la configuracion de las transacciones pasar de 'no wait' a 'wait'. ¿que opinais?
__________________
Saludos, Bitman |
#13
|
|||
|
|||
Como no podia reproducir el fallo con el uso normal de la aplicación, he modifcado las aplicaciones para que con un timer realicen operaciones cada X segundos, de esta forma ejecuto varias instancias y puedo realizar pruebas de concurrencia. Pues de esta forma si he podido finalmente reproducir los errores. Ahora que ya puedo reproducir el fallo, he probado esto ultimo que comentaba de cambiar de 'no wait' a 'wait' y con este tipo de transacciones ya no sucede el fallo. De hecho ni intentando provocarlo.
Imagino que este modo de transaccion tiene que penalizar quizas en rendimiento, aunque en mi caso que son pocos usuarios (<15) no lo he notado. ¿que opinais?
__________________
Saludos, Bitman |
#14
|
|||
|
|||
Hola,
Continuando con la depuracion de este error ya que quiero solucionarlo de la mejor manera (las otras soluciones que comentaba eran mas para el parche inmediato) he añadido en la aplicación unos indicadores en el formulario principal que me indican el estado de las transacciones, para de esta forma poder controlar mas facilmente en tiempo de ejecucion donde estoy gestionando mal las transacciones. Me he llevado la primera sorpresa en una pantalla tipo edicion de un 'albaran', la cual como el resto de la aplicación utilizo clientdatasets para precisamente mejorar la gestión de las transacciones. Pues bien hay algo que no debo estar haciendo bien ya que gracias a estos indicadores veo que la transaccion que utilizo para la edición de las lineas de un albaran se queda abierta. Añadir lo siguiente, en la aplicación utilizo dos tipos de transacciones una para las consultas que no modifican la base de datos y otra para las que si pueden actualizar datos:
En el caso de las transacciones de consulta me lo gestiona correctamente, realizo la query, me carga los datos en el CDS y automaticamente me cierra la transacciones con un rollback. En el otro caso no. Tengo claro que es por la configuracion diferente del TIBtransacction, pero como deberia tenerlo configurado para para este tipo de uso?
__________________
Saludos, Bitman |
#15
|
||||
|
||||
¿2 TIBtransaction?
¿Entonces tienes también 2 TIBdatabase? |
#16
|
|||
|
|||
No, tengo un solo TIBDatabase. Sino recuerdo mal lo habia leido y comentado por aqui el uso de varios TIBTransacction con una sola base de datos.. No es correcto?
__________________
Saludos, Bitman |
#17
|
||||
|
||||
Ahora mismo no recuerdo ese tema, tendría que revisar algún proyecto antiguo, aunque juraría que siempre he usado una ibdatabase con una ibtransaction.
|
#18
|
|||
|
|||
Pero esto no veo que me de problemas, ya que como he comentado he puesto unos indicadores del estado de cada TIBtransacction y el de la transaccion de lectura funciona correctamente y es el que utilizo para las actualizaciones el que se queda activo.
Ademas es solo en el caso de cargar un CDS con varios datos para editarlos y guardar los cambios posteriormente. Durante el tiempo de edicion se queda la transaccion abierta. Y esto es porque yo pensaba que automaticamente el DataSetProvider la cerraba. Pero creo que el problema es que no tenia definida la propiedad AutoStopAction del TIBTrasacction. Y lo tenia como saNone. Estoy en lo cierto? Que opinas?
__________________
Saludos, Bitman |
#19
|
||||
|
||||
A ver si otro compañero puede ayudarte, yo no trabajo de esa forma, así que no puedo confirmarte si es correcto lo que haces.
|
#20
|
|||
|
|||
Me contesto yo mismo con una respuesta de un foro de 'Borland' por el señor Jeff Overcash:
Cita:
__________________
Saludos, Bitman Última edición por Casimiro Notevi fecha: 14-09-2015 a las 20:35:44. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Conflicto con archivos | danielmj | Varios | 8 | 26-09-2013 16:50:16 |
El conflicto en medio oriente | gatosoft | La Taberna | 25 | 05-01-2009 23:03:28 |
Conflicto al Imprimir ¿? | Alejandro73 | Impresión | 0 | 01-02-2008 20:01:28 |
Conflicto con SQL Dialect BDE | rikr2rv | Firebird e Interbase | 2 | 28-08-2007 23:58:04 |
Conflicto con Session1. | danytorres | Varios | 10 | 30-06-2005 23:33:56 |
|