Problema con Lock conflict

[Leopard2]

Hola, tengo un programa de facturas, el primero hecho con firebird 2.5 y los IBX de Delphi 7 y me da este error en distintas operaciones (borrar, ingresar, modificar), al parecer un usuario deja la tabla o una transacciòn colgada, que opinan de cual puede ser el motivo del mensaje ?
Saludos

[Casimiro Notevi]

Nunca había visto un deadlock con firebird, tendrían que darte un premio
Solucionar esto puede ser fácil o muy, muy difícil. Todo depende de cómo hayas programado el sistema.
Para empezar, ¿qué parámetros tienes en el TIBTransaction?

[[RONPABLO]]

Empezado por Leopard2

Hola, tengo un programa de facturas, el primero hecho con firebird 2.5 y los IBX de Delphi 7 y me da este error en distintas operaciones (borrar, ingresar, modificar), al parecer un usuario deja la tabla o una transacciòn colgada, que opinan de cual puede ser el motivo del mensaje ?
Saludos

acá podrás mirar porque salen los bloqueos en firebird. La ídea es que compare con su transacción y mire porque pasa.


Por cierto, algo que me pasaba antes con respecto a estos bloqueos era que usaba componentes del tipo DBEdit o similares, entonces por decir algo alguien empezaba a escribir en un dbEdit y acá arrancaba una transacción y después de mucho rato seguía abierta y sin un commit a la vista. Luego desde otro equipo alguien más trataba de guardar algo pero en el equipo original había aún una transacción esperando a realizar ya fuera commit o rollback... Lo mejor es evitar eso y hacer transacciones lo más pequeñas posibles.

ejemplo

Código Delphi [-]
try
   Transaccion.(iniciartransaccion)   // No recuerdo el comando que inicia una transacción
   DSPersonas.FIeldByName('nombre').asstring =  'Jose';
   DSPersonas.FIeldByName('telefono').asstring =  '3158872244';
   DSPersonas.post;
   DSPersonas.ApplyUpdates;
   Transaccion.commit;
except
   Transaccion.rollback;

[Leopard2]

Empezado por Casimiro Notevi

Nunca había visto un deadlock con firebird, tendrían que darte un premio
Solucionar esto puede ser fácil o muy, muy difícil. Todo depende de cómo hayas programado el sistema.
Para empezar, ¿qué parámetros tienes en el TIBTransaction?

donde paso a retirar mi premio jajaja ? en serio, que origina los deadlock ?

[Casimiro Notevi]

[RONPABLO], si tiene bien configurado los parámetros del TIBTransaction, él se encarga de las transacciones, no hay que preocuparse de nada.
No es necesario iniciar/confirmar una transacción, salvo que sea "larga" y tenga implicada varias tablas que deseemos que tengan "consistencia". Para ello se usaría de forma similar a como has descrito.

[Casimiro Notevi]

Empezado por Leopard2

donde paso a retirar mi premio jajaja ?

Botón derecho en el componente y mira los parámetros.

[Leopard2]

Empezado por RONPABLO

acá podrás mirar porque salen los bloqueos en firebird. La ídea es que compare con su transacción y mire porque pasa.


Por cierto, algo que me pasaba antes con respecto a estos bloqueos era que usaba componentes del tipo DBEdit o similares, entonces por decir algo alguien empezaba a escribir en un dbEdit y acá arrancaba una transacción y después de mucho rato seguía abierta y sin un commit a la vista. Luego desde otro equipo alguien más trataba de guardar algo pero en el equipo original había aún una transacción esperando a realizar ya fuera commit o rollback... Lo mejor es evitar eso y hacer transacciones lo más pequeñas posibles.

ejemplo

Código Delphi [-]
try
   Transaccion.(iniciartransaccion)   // No recuerdo el comando que inicia una transacción
   DSPersonas.FIeldByName('nombre').asstring =  'Jose';
   DSPersonas.FIeldByName('telefono').asstring =  '3158872244';
   DSPersonas.post;
   DSPersonas.ApplyUpdates;
   Transaccion.commit;
except
   Transaccion.rollback;

ocupo los DBEdit y IBDataset para las tablas :

MasterDb.ReqmtoMas.Post;
Try
Masterdb.IBTrsc.CommitRetaining;
ShowMessage('! REQUERIMIENTO GRABADO CORRECTAMENTE !');
Except
MasterDb.ReqmtoMas.Cancel;
Masterdb.IBTrsc.RollbackRetaining;
ShowMessage('Se produjo un error y no se grabarón los datos');
end;

[Casimiro Notevi]

Recuerda poner los tags al código fuente, ejemplo:



Gracias

[Leopard2]

Empezado por Casimiro Notevi

Botón derecho en el componente y mira los parámetros.

[[RONPABLO]]

Empezado por Leopard2

ok, ahora con esos parámetros compara con el link que envié anteriormente y mira... así por encima lo que vi era que el nowait es uno de los que genera el deadLock, allá ene se enlace lo explican que va a pasar.

[Casimiro Notevi]

Hace falta más información, ¿usas más de un tibtransaction? ¿qué código está usando? etc.
Yo siempre he usado esos parámetros, desde 1998, y nunca he visto un deadlock.

[Leopard2]

Empezado por RONPABLO

ok, ahora con esos parámetros compara con el link que envié anteriormente y mira... así por encima lo que vi era que el nowait es uno de los que genera el deadLock, allá ene se enlace lo explican que va a pasar.

Gracias por el link, muy buena pagina, mañana voy a probar el Wait de la transacción, yo también creo que por ahí va la cosa.
saludos

[[Lepe]]

Yo también prefiero no usar controles DB, mejor hacerlos por Edits normales. Así la transacción empieza cuando el usuario pulsa el botón de aceptar y sabemos que terminará enseguida.

O eso, o usar ClientDatasets... un poco más latoso al principio de entender, pero puedes usar DBEdits. Tienes disponibles todos los eventos de esos controles DB. La transacción no empieza cuando editas un DBEdit. El botón aceptar se convierte en un ClientDataset1.ApplyUpdates; y ahí se aplican todos los cambios de golpe.

Para controlar los errores de 2 usuarios concurrentes, se usa File -> new -> Other -> Dialogs -> Reconcile Error Dialog
Es una ventana que le aparecerá al segundo usuario que intenta grabar el mismo registro que otro usuario se adelantó a grabar. Le dice qué campos tienen conflictos y los valores de los 2 usuarios. Además le pide al segundo usuario que resuelva el conflicto:
- guardar los datos que introdujo el primer usuario
- guardar los datos que ha introducido él mismo.

Saludos!

[Leopard2]

Al final el problema era que había un Update del correlativo que quedaba fuera del Commit cuando se cancelaba el ingreso y quedaba la transacción abierta y si venia otro usuario a ocupar la misma tabla provocaba que apareciera el error.
De todas maneras cambie de NoWait a Wait la configuración de las transacciones.
Ahora lei que hay una tabla que lleva el registros de las transacciones y supongo que esa transacción muerta queda almacenada, al hacer un backup y restore se limpia dicho registro ?
Saludos y gracias por sus aportes.