Transacciones, que locura!

[sierraja]

Buenos dias,

Realmente el titulo se aplica cuando no se entiende nada al respecto, he leido varios post, inclusive documentos y explicaciones al respecto, pero me he sentido frutstrado, porque no he podido resolver la situacion, quisiera por favor una orientacion mas concreta. (pido disculpas por no entender nada despues de todo). El escenariko es el siguiente: Aplicacion trata sobre facturacion de consumo de agua, esta montado en un server linux con firebird 1.5 y lo acceso desde delphi con IBX. EL problema surge que, existe un cajero realizando la facturacion sobre una tabla (donde se prensentan las facturas) pero cuando se, pero cuando se consulta un estado de cuenta sobre el mismo suscriptor pero en otra maquina, siempre me aparece el dead lock, entonces hay que salir de la facturacion para poder sacar el estado de cuenta, o viceversa salir del estado de cuenta para poder facturar. el setup de la transaction es read_commit, rec_verson, nowait, y tengo este componente para el form de facturacion y otro form para el estado de cuenta con su respectiva transaction. La pregunta es como deberia configurar las transacciones para cada proceso. He realizado varias pruebas de distintas maneras pero siempre me genera el abrazo de la muerte. Gracias por su valioso tiempo.

[jhonny]

¿En la generación de dicho estado de cuenta, de pronto estas tratando de escribir en el mismo registro que esta abierto por el cjaero, en ese momento?

[sierraja]

Eso es correcto hice una revision minuciosa y la rutina de generar el estado de cuenta, me estaba ejecuntando un update de la misma tabla, efectivamente dicho update no era necesario de por si, entonces procedi a eliminarlo y ha funcionado muy bien. Gracias por tu tiempo

[jhonny]

Empezado por sierraja

Eso es correcto hice una revision minuciosa y la rutina de generar el estado de cuenta, me estaba ejecuntando un update de la misma tabla, efectivamente dicho update no era necesario de por si, entonces procedi a eliminarlo y ha funcionado muy bien. Gracias por tu tiempo

Que bien , eso me alegra.

[cloayza]

Como saber tanto ..........jhonny

Realizando una simple pregunta se soluciona todo...Fantastico.

Saludos

[andresenlared]

saludos...

respecto a las locuras de las tranascciones como se puede evitar el abrazo mortal cuando dos aplicaciones estan accediendo al mismo tiempo al mismo registro...por ejemplo la aplicacion A esta actualizando el registro 5 de la tabla T1 y la aplicacion B esta realizando una actualizacion en otro campo del mismo registro en la tabla T1....son situaciones que efectivamente se pueden presentar cuando se trabajan diferentes aplicaciones sobre una misma base de datos...pero cual seria la mejor forma de controlar estas situaciones.?

[Casimiro Notevi]

Te aconsejo este libro, es un pdf, haz una búsqueda por "deadlock", creo que te resultará útil.

[Jab]

Empezado por andresenlared

saludos...

respecto a las locuras de las tranascciones como se puede evitar el abrazo mortal cuando dos aplicaciones estan accediendo al mismo tiempo al mismo registro...por ejemplo la aplicacion A esta actualizando el registro 5 de la tabla T1 y la aplicacion B esta realizando una actualizacion en otro campo del mismo registro en la tabla T1....son situaciones que efectivamente se pueden presentar cuando se trabajan diferentes aplicaciones sobre una misma base de datos...pero cual seria la mejor forma de controlar estas situaciones.?

Pienso que aquí lo mejor es prevenir. Es decir, si dos o más usuarios van a modificar un registro lo mejor es que el primero que interviene lo establezca como propio y el resto lo único que puedan entrar es en modo lectura, de esta manera, evitamos que dos usuarios modifiquen una información sobre un registro que en principio no debería ocurrir según qué casos.

Respecto a tu especificación concreta, pienso que deberías revisar la Forma Normal de tu base y si se relaciona correctamente con la lógica de los procesos. Un usuario no debería tener el privilegio de modificar una parte de un registro y otro otra parte. Divide esa tabla en dos que se relacionen, es posible que no hayas establecido bien las entidades.

Si no es así, establece un sistema de prioridades y crítico, quiero decir, que existe código crítico que debe resolverse en poco tiempo. Puedes utilizar en este caso un update directo sobre la base y su consecuente transacción. En teoría como ambos usuarios modifican diferentes partes del registro el cual no se puede dividir en dos o más tablas, dará lo mismo cuando actualicen ya que los datos que no modifiquen no deberían verlos.

Saludos.