Averiguar conflicto por bloqueo

[Toni]

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.

[Casimiro Notevi]

Bien, entonces parece que ahí tienes los problemas.

[[RONPABLO]]

Empezado por Toni

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.

Yo tenía esos problemas cuando una transacción duraba mucho tiempo y alguien más entraba a editar una tabla que estuviera siendo afectada en esa transacción larga, especialmente me pasaba con componentes al estilo DBEdit, DBCombobox o cualquier otro similar a un DBXXX, la solución, buscar donde se pueden dar esos procesos de transacción demoradas (cuando por ejemplo en un DBEdit se hace un cambio del dato que contiene, este entra en modo edición y bloquea un registro especifico de tabla, y solo al hacer commit se ve nuevamente dicho registro de dicha tabla liberado...

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

[Casimiro Notevi]

Eso no debe suceder si la transacción está configurada así:

read_committed
rec_version
nowait

[Toni]

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?

[Toni]

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?

[Toni]

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:

Código SQL [-]
Paramertros TIBTransacction consultas

AutoStopAction=saRollback
DefaultAction=TARollback
IdleTimer=0
Params=Snapshot {concurrency, nowait}

Código SQL [-]
Paramertros TIBTransacction actualizaciones

AutoStopAction=saNone
DefaultAction=TACommit
IdleTimer=0
Params=Read Commited {read commited, recversion, nowait}

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?

[Casimiro Notevi]

¿2 TIBtransaction?
¿Entonces tienes también 2 TIBdatabase?