Problemon , Oldest active y Oldest transaction , corrompe la bd.

[tefots]

Bueno, no se como explicar el problema exactamente pero el caso es que me está provocando bastantes dolores de cabeza , debido a que se me quedan transacciones sin finalizar (bueno realmente se quedan perdidas) , y llega un momento en que la base de datos se jode y se corrompe debido a las innumerables transacciones que se quedan perdidas.

ejemplo de un rato de funcionamiento

Flags 0
Checksum 12345
Generation 24181
Page size 4096
ODS version 11.0
Oldest transaction 21955
Oldest active 21956
Oldest snapshot 21943
Next transaction 24172
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 16
Shadow count 0
Page buffers 4096

(como veis hay diferencia entre oldest active y next transaction).
todas las transacciones se inician y finalizan correctamente , excepto una transaccion (la que por defecto se asigna a la base de datos) que se queda activa.

El entorno es el siguiente . uso ibexpres , atacando a fb2.0. y varios clientes y distintas aplicaciones atacando a la base de datos. por su naturaleza , algunas de estas aplicaciones , han de estar encendidas 24 horas al año.

Inicialmente pensaba que el problema era alguna transaccion que me dejaba abierta , luego pense que era por hacer commitretaining en vez de commit , lo que me obligó a realizar varios cambios en distintas aplicaciones , pero no , despues de varias pruebas , el verdadero problema , es que al hacer commit o commitretaning , firebird deja las transacciones perdidas en el hiperespacio mientras haya alguna otra aplicacion/cliente que mantenga una transaccion activa y no finalizada.

para muestra , he hecho un programita de prueba , que mantiene una transaccion abierta , y genera insercciones repetitivamente hasta el infinito (cada una con su starttransaction y commit) , pues bien , mientras se mantenga una transaccion activa , (la misma aplicacion o cualquier otra aplicacion) , las transacciones se quedan en hiperespacio , y llega un momento que al haber tantas , pues la bd se ralentica y se corrompe.
sin embargo , si se cierra la transaccion que mantenemos activa , entonces es cuando esas transacciones se 'liberan' por llamarlo de alguna forma.

un simple progamita como este , que realice inserciones masivas en una base de datos , y manteniendo por encima una transaccion activa (la que por defecto esta asociada a tibdatabase ) , hace que las transacciones se queden perdidas en el hiperespacio.

Código Delphi [-]
 
  Q:=TIBQUERY.CREATE(SELF);
  Q.SQL.ADD('INSERT INTO PRUEBA (NOMBRE,TELEFONO) VALUES (:N,:T)');
  Q.ParamByName('N').DataType:=FTSTRING;
  Q.ParamByName('T').DataType:=FTINTEGER;
  Q.Transaction:=IBTransaction2;
  WHILE (NOT FIN) DO BEGIN
    TRY
      if not IBTransaction2.Active then
        IBTransaction2.StartTransaction;
      Q.ParamByName('N').value:='NOMBRE '+inttostr(CONTADOR);
      Q.ParamByName('T').value:=CONTADOR;
      q.ExecSQL;
      IBTransaction2.Commit;
    EXCEPT
      IBTransaction2.Rollback;
    End;
    Application.ProcessMessages;;
    Label2.Caption:='Transaccion nº'+inttostr(contador);
    Inc(Contador);
  End;
  Q.free;

como el funcionamiento es ese y no lo puedo modificar , el problema es que , como tengo aplicaciones que han de mostrar datos de la bd y mantener una transaccion siempre activa , y por otra parte hay procesos que insertan modifican y borran con su correspondiente transaccion , como todo ello ha de estar 24 horas al año enmarcha , al final al cabo de un mes , la base de datos dice 'basta' , se ralentiza , se corrompe y peta.

A mi modo de ver , y a no ser que este equivocado , todo esto es un fallo de diseño muy grave de firebird , que hace que no pueda ser usado en entornos de produccion , en los que se necesite siempre tener una transacccion activa y la aplicaciones funcionando 24horas, ya que al final la base de datos acaba petando con el consiguiente problema.

en fin , una solucion busco a todo este rollo.. .

Saludos.