Averiguar conflicto por bloqueo

[Toni]

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!

[ecfisa]

Hola Toni.

Fijate si te resulta útil: How to detect applications and users that hold transactions open too long?

Saludos

[Toni]

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!

[Toni]

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.

[Casimiro Notevi]

Que te digan exactamente en qué pantalla ocurrió y qué estaban haciendo.

[Toni]

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.

[Casimiro Notevi]

Pero, ¿qué error es el que muestra?

[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?

[Toni]

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?

[Casimiro Notevi]

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.

[Toni]

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?

[Casimiro Notevi]

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.

[Toni]

Me contesto yo mismo con una respuesta de un foro de 'Borland' por el señor Jeff Overcash:

This means the transaction is started before you called ApplyUpdates.
DataSnap only commits the transaction if it starts it. You should
never touch the transaction for a DataSnap driven IBX query. The
transaction's AutoStopAction should always be set to saCommit and
PacketRecords needs to stay -1. This causes the transaction to be
closed after reading the data so it is in the right state when the CDS
tries to Apply the updates.

Y en el que tambien comentan el uso de varias transacciones sin problemas. En el caso de utilizar CDS+DSP+QRY no hay que utilizar nunca las llamadas de commit y rollback directamente al TIBTransacction.