Ir al contenido


Foto

¿Cómo "corto" una transacción pendiente?


  • Por favor identifícate para responder
4 respuestas en este tema

#1 TiammatMX

TiammatMX

    Advanced Member

  • Miembros
  • PipPipPip
  • 1.750 mensajes
  • LocationUniverso Curvo\Vía Láctea\Sistema Solar\Planeta Tierra\América\México\Ciudad de México\Xochimilco\San Gregorio Atlapulco\Home

Escrito 14 octubre 2013 - 08:26

Buen día/tarde/noche (según aplique), jóvenes Delphineros...

Les platico que en casa tengo Firebird 2.1 conectado a mi aplicación mediante ADO (sí, yo sé que no es lo óptimo, pero así me lo requirieron) y sucedió algo que me alarma y me da un poco de desconfianza. Resulta que durante alguna de las múltiples pruebas a una pantalla que estoy desarrollando, mandé actualizar un campo que es vital para el funcionamiento del programa, de tipo VarChar(20); una vez que SE SUPONE que grabó el dato, me aparece una excepción en que se involucra a uno de los campos llave para recrear los datos en memoria (un Refresh, pues), corrijo el problema y vuelvo a probar...

Cuál va siendo mi sorpresa que NO ME PERMITE ACTUALIZAR EL CAMPO VARCHAR nuevamente, es más, utilizando un manejador de Firebird le intento actualizar el dato a mano e INVARIABLEMENTE se queda con el valor anterior a la actualización por más intentos (mediante Commit a la transacción) que le haga de modificarlo.

Preguntas, ¿será que debo recrear la tabla, cómo puedo evitar que ésto quede en el entorno real de trabajo para mi cliente? ¿Cómo puedo solucionarlo para continuar avanzando en la programación en lo que diseño una estrategia para que ésto no suceda?

Agradeciendo de antemano.
  • 0

#2 Rolphy Reyes

Rolphy Reyes

    Advanced Member

  • Moderadores
  • PipPipPip
  • 2.092 mensajes
  • LocationRepública Dominicana

Escrito 14 octubre 2013 - 09:23

Saludos.

Al parecer ese registro en particular se quedo bloqueado, intenta con un Backup/Restore.

En cuanto a la transacción puede influir el nivel de aislamiento que estés utilizando en la conexión. Los TADOQuery viene por defecto con las propiedades LockType = ltOptimistic y MarshalOptions = moMarshalAll, pudieras probar cambiar el valor de la ultima por moMarshalModifiedOnly.

¿Abres alguna transacción de manera explicita para realizar la operación? Si es afirmativa la respuesta, ¿La operación esta dentro de un bloque que realice un Commit o Rollback?
  • 0

#3 TiammatMX

TiammatMX

    Advanced Member

  • Miembros
  • PipPipPip
  • 1.750 mensajes
  • LocationUniverso Curvo\Vía Láctea\Sistema Solar\Planeta Tierra\América\México\Ciudad de México\Xochimilco\San Gregorio Atlapulco\Home

Escrito 14 octubre 2013 - 10:28

...Al parecer ese registro en particular se quedo bloqueado, intenta con un Backup/Restore...

Gracias por el consejo. No quería llegar a éste punto, pero creo que tendré que realizar el procedimiento...

...En cuanto a la transacción puede influir el nivel de aislamiento que estés utilizando en la conexión. Los TADOQuery viene por defecto con las propiedades LockType = ltOptimistic y MarshalOptions = moMarshalAll, pudieras probar cambiar el valor de la ultima por moMarshalModifiedOnly...

Haré los cambios pertinentes al TADOQuery, afortunadamente como es un componente heredado, podré hacer el movimiento una sola vez.

...¿Abres alguna transacción de manera explicita para realizar la operación? Si es afirmativa la respuesta, ¿La operación esta dentro de un bloque que realice un Commit o Rollback?...

No abro transacción, especialmente por que aún no había llegado al punto de necesitarla (sigo desarrollando) pero ciertamente es algo que tengo contemplado. Finalmente, como utilizo componentes DataAware conectados directamente a la tabla, no tengo la más pálida idea de dónde hacerle el Commit/Rollback; ¿sería en BeforePost o en qué evento me lo recomiendas?
  • 0

#4 Sergio

Sergio

    Advanced Member

  • Moderadores
  • PipPipPip
  • 1.092 mensajes
  • LocationMurcia, España

Escrito 15 octubre 2013 - 02:58

Respecto del backup-restore, prueba antes a desconectar el FB server y reconectarlo (desde panel de control), lo mas seguro es que la conexion sigua viva desde el punto de vista de FB y este esperando un commit o un roolback que nunca llegará. Esto debería "soltar" la transacción que quedó activa como si hicieses un roll-back.

Supongo que lo que ocurrió es que enviaste el cambio -post- pero no llego nunca commit por el fallo que te dio, y si no tienes previsto un rollback en caso de fallo, el sistema se te puede quedar con un cambio "pendiente" que hace que sea, por un lado, invisible a las transacciones tipo "read_commited" (porque no hubo commit) y no editable para nadie (lees la version antigua del record, pero al grabar existe otra mas moderna a medio aceptar y puede darse un dead-lock... un lio, vamos).

En partes del programa donde el cambio sea "vital", necesitas un try except con su rollback o estarás expuesto a esto, eso sí, ocurrir ocurre poco y es cuestión de bastante mala suerte, pero antes o despues te va a pasar.
  • 0

#5 Sergio

Sergio

    Advanced Member

  • Moderadores
  • PipPipPip
  • 1.092 mensajes
  • LocationMurcia, España

Escrito 15 octubre 2013 - 03:05

Otra forma de cancelar la transaccion pendiente sin matar a nadie:

Shut down database, force shutdown NOW
gfix -user SYSDBA -password masterkey dbserver:/db/mydb.fdb -shut -force 0

Put database online again
gfix -user SYSDBA -password masterkey dbserver:/db/mydb.fdb -online[/firebird]

Sacado de: http://www.destructo...rebird/gfix.htm
  • 0




IP.Board spam blocked by CleanTalk.