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

[pvizcay]

hola,
mira puede que este guitarreando porque eso lo leí del firebird book hace un tiempo y no lo volví a repasar, pero según tengo entendido si tienes al menos UNA sola transacción abierta por tiempo indeterminado sucede lo que comentas.. y más en un programa corriendo las 24hs como dices..

yo creo que la solución es que TODAS las transacciónes se inicien y terminen en el menor tiempo posible.. (indispensable si el programa corre todo el tiempo desde mi punto de vista).. no se que papel juega esa transacción que dejas todo el tiempo pero tendrías que cambiar la arquitectura de la aplicación para que eso no suceda más..

si tienes el firebird book hay 3 capitulos de transacciones que te explican TODO.. son un poco densos pero realmente indispensables

salu2 espero que mi respuesta esté bien encaminada..

[[duilioisola]]

excepto una transaccion (la que por defecto se asigna a la base de datos) que se queda activa

Esta transaccion (si no me equivoco) es solo para que los componentes que dependen del componente BaseDeDatos la utilicen por defecto.

Prueba ese programita que has hecho con una modificación.

Una vez que te conectes haces commit de la transaccion que se asigna a la base de datos y luego sigues (con los insert).

Dime si esto soluciona el problema.

[[duilioisola]]

24 horas al año no es demasiado ... todavía te quedan 8736 horas en el ano para apagar la aplicacion

[tefots]

el tema esta claro , mientras tenga una transaccion activa , el resto de transacciones por muy bien que las haya finalizado , se quedan pendientes realmente.
tambien tengo claro , que lo ideal para hacer cualquier operacion sobre la bd , es conectarse , iniciar transaccion , realizar operaciones , finalizar transaccion y desconectarse. lo qe pasa es que esto por la naturaleza de las aplicaciones no siempre es posible, y de serlo para poder llevarlo a cabo hay que realizar trabajo extra.

la cosa es que en una aplicación tengo controles enlazados que muestran alarmas, eventos , etc... . la aplicacion (ademas de hacer otras cosas ) como ya he dicho ha de estar siempre en marcha y estas pantallas han de estar siempre mostrandose.
y para mostrar todos estos datos he de tener siempre una transacion activa , (ademas d que el usuario puede abrir pantallas y dejarlas abiertas hasta el final de los dias , las cuales tambien usan transacciones) , asi que aqui esta el problema.
la solucion ya la se , y es cada x tiempo (digamos 1 hora) , cerrar e iniciar de nuevo las transacciones activas que tenga , sin que el usuario y sin que los controles enlazados que usan esta transaccion se enteren .
pero me parece una verdadera chapuza y una perdida de tiempo andar realizando estas cosas simplemente porque sino la base de datos peta con el tiempo.

como ya he dicho me parece un fallo muy grave , y no creo que yo haya diseñado la aplicación mal , sino que hay que diseñar la aplicacion cliente de tal forma que aunque se inicien y finalizen las transacciones correctamente , si no se tiene en cuenta , al final la bd acaba corrompiendose .
¿donde se ha visto un SGBD que por que un cliente deje una transaccion abierta , la base de datos acabe corrompiendose ?.
en fin que no volvere a usar firebird para proyectos futuros hasta que estos temas no este solucionados realmente.

saludos.

[pvizcay]

Empezado por tefots

el tema esta claro , mientras tenga una transaccion activa , el resto de transacciones por muy bien que las haya finalizado , se quedan pendientes realmente.

mmm no, no se quedan pendientes, ya están en commit o completadas.. pero el punto es que la performance se degrada como dices..

Empezado por tefots

tambien tengo claro , que lo ideal para hacer cualquier operacion sobre la bd , es conectarse , iniciar transaccion , realizar operaciones , finalizar transaccion y desconectarse. lo qe pasa es que esto por la naturaleza de las aplicaciones no siempre es posible, y de serlo para poder llevarlo a cabo hay que realizar trabajo extra.

"no siempre es posible" ?? yo creo que si, tal vez tengas que cambiar el diseño de la aplicación.. tal vez si de entrada sabías como funcionaba firebird y su arquitectura multigeneracional te hubieras ahorrado el trabajo..

Empezado por tefots

la cosa es que en una aplicación tengo controles enlazados que muestran alarmas, eventos , etc... . la aplicacion (ademas de hacer otras cosas ) como ya he dicho ha de estar siempre en marcha y estas pantallas han de estar siempre mostrandose.
y para mostrar todos estos datos he de tener siempre una transacion activa , (ademas d que el usuario puede abrir pantallas y dejarlas abiertas hasta el final de los dias , las cuales tambien usan transacciones) , asi que aqui esta el problema.

para alarmas y eventos FB tiene los events.. la aplicación cliente que los "escucha" no tiene que crear una transacción para los mismos.. asi que esto es claramente falso

Empezado por tefots

la solucion ya la se , y es cada x tiempo (digamos 1 hora) , cerrar e iniciar de nuevo las transacciones activas que tenga , sin que el usuario y sin que los controles enlazados que usan esta transaccion se enteren .
pero me parece una verdadera chapuza y una perdida de tiempo andar realizando estas cosas simplemente porque sino la base de datos peta con el tiempo.

puedes hacer que las pantalla cargue los datos y luego cerrar la transacción.. (con controles no enlazados por ej); si es una operación interactiva no hace falta que quede un día la ventana abierta.. si te pones a pensar como solucionarlo encontraras 100 maneras elegantes de realizarlo..

Empezado por tefots

como ya he dicho me parece un fallo muy grave , y no creo que yo haya diseñado la aplicación mal , sino que hay que diseñar la aplicacion cliente de tal forma que aunque se inicien y finalizen las transacciones correctamente , si no se tiene en cuenta , al final la bd acaba corrompiendose .
¿donde se ha visto un SGBD que por que un cliente deje una transaccion abierta , la base de datos acabe corrompiendose ?.
en fin que no volvere a usar firebird para proyectos futuros hasta que estos temas no este solucionados realmente.

saludos.

yo creo que si la diseñastes mal y estas enojado con firebird por eso.. es más gran parte del problema viene por los componentes de acceso a datos que usas que están pensados para programas con otros requerimientos.. si quieres algo mas tienes que escribir un poco de código.. diseñar una aplicación que corre 24x356 no es trivial, y ni siquiera hicistes una pequeña investigación de la tecnología que usastes.. yo creo que puedes aprender algo de todo esto que te sucedió.. éxitos!

[tefots]

Hola , gracias por responder.

Empezado por pvizcay

mmm no, no se quedan pendientes, ya están en commit o completadas.. pero el punto es que la performance se degrada como dices..

exacto , aqui esta el problema y la gran cagada de firebird. la performance se degrada , y al final se corrompe , te lo aseguro.
[/quote]

Empezado por pvizcay

para alarmas y eventos FB tiene los events.. la aplicación cliente que los "escucha" no tiene que crear una transacción para los mismos.. asi que esto es claramente falso

no me referia a los events de firebird , con esto me referia a que muestro una serie de registros que guardan alarmas y eventos de diversos tipos, tambien estados de distintos equipos hardware. todo ello con controles enlazados (dbgrid's , etc).

Empezado por pvizcay

puedes hacer que las pantalla cargue los datos y luego cerrar la transacción.. (con controles no enlazados por ej); si es una operación interactiva no hace falta que quede un día la ventana abierta.. si te pones a pensar como solucionarlo encontraras 100 maneras elegantes de realizarlo..

Siempre he usado controles enlazados , creo que es una de las cosas en las que delphi se aventaja de sus adversarios. si por usar firebird , en algunos casos no voy a poder usar controles enlazados (que esten permanentemente mostrandose) , o voy a tener problemas por usarlos , creo que es un paso atrás y una desventaja en vez de una ventaja.
como bien dices , hay muchas formas de solucionar el problema , pero no habria nada que solucionar si firebird no tuviera dicho problema.

Empezado por pvizcay

yo creo que si la diseñastes mal y estas enojado con firebird por eso.. es más gran parte del problema viene por los componentes de acceso a datos que usas que están pensados para programas con otros requerimientos.. si quieres algo mas tienes que escribir un poco de código.. diseñar una aplicación que corre 24x356 no es trivial, y ni siquiera hicistes una pequeña investigación de la tecnología que usastes.. yo creo que puedes aprender algo de todo esto que te sucedió.. éxitos!

No estoy enojado con firebird (solo conmigo mismo por haberlo elejido) , llevo usandolo en todas sus versiones , desde que se liberó ib6 , así que unas cuantas pruebas si que he hecho. lo que no sabia era que la bd se degradaba al mantener una transaccion activa (supongo que la mayoria de usuarios fb no lo saben) , ya que la > de aplicaciones no corren 24x365.

Escribiendo un poco de código todo puede hacerse , pero los controles gráficos enlazados están para que el programador pierda el menor tiempo posible en esto , dile a alguien que está acostumbrado a usar un dbgrid que para que firebird no se degrade , que use un stringgrid , o mejor aun que lo pinte directamente en el canvas.

Como ya he dicho , un sgbd que se degrada porque un cliente mantiene una transaccion activa , no me parece un sgbd serio. independientemente del tiempo que un cliente mantenga una transaccion abierta , fb deberia mantener el performance y la integridad de los datos , y no lo hace.

No hay que ser taliban de firebird (que nadie se ofenda) , para un tipo de aplicaciones firebird va muy bien (de hecho llevo usandolo y defendiendolo muchos años) , pero para otro tipo de aplicaciones , es mejor no usarlo (o se si usa , hay que tener en cuenta algunas cosas para que no se degrade).


Saludos