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.