[Casimiro Notevi]

Empezado por rolandoj

Cuando hablaba de limpieza automática me refería sobretodo a los registros inservibles que tuvieron vida durante la transacción. Según lo que leí, al usar el método Commit de Zeos ellos no se limpian automáticamente. Para que se de la operación de limpieza hay que cerrar la conexión.

Ni zeos, ni ibx, ni fibplus, ni ninguno... es que no tiene nada que ver con los componentes que estés usando. Tampoco tiene que ver con que hagas commit, commitretaining, rollback, etc. Firebird tiene una Arquitectura Multi Generacional, guarda "distintas versiones" de un mismo registro, lee esto:

El control de concurrencia
Considere la posibilidad de una simple aplicación bancaria en la que dos usuarios tienen acceso a los fondos en una cuenta particular. Bob lee la cuenta y encuentra que hay 1.000 dólares en ella, por lo que retira 500. Jane utiliza la misma cuenta pero antes de que Bob haya aplicado los cambios, considera que hay 1000 dólares y retira 800. La cuenta debería tener 300 dólares en descubierto, sin embargo (asumiendo que no puede haber descubierto) dependiendo de la transacción que se procese primero, tendrá 500 ó 200 dólares. Esto plantea un grave problema ante el cual cualquier sistema de bases de datos con acceso multiusuario debe responder ofreciendo un sistema con el que gestionar estas situaciones.
Las técnicas utilizadas para resolver este y otros problemas relacionados, son conocidos como control de concurrencia .
Los productos tradicionales utilizan bloqueos cuando una determinada transacción va a modificar un registro. Una vez que el bloqueo se aplica, nadie más puede leer o modificar los datos hasta que éste se levante. El bloqueo se puede aplicar sobre un único registro, una página (un grupo de registros almacenados juntos en el disco) de registros o todos los registros examinados por una transacción en particular, dependiendo de la resolución de bloqueo. El bloqueo de resolución es una solución de compromiso entre rendimiento y precisión mediante la aplicación de bloqueo de actualizaciones a nivel de página. Algunos registros serán bloqueados a pesar de no entrar en conflicto con aquellos que sí van a ser actualizados por transacciones, sin embargo el rendimiento es mayor en comparación con el bloqueo a nivel de registro.
El bloqueo se convierte en un problema aún mayor cuando se combina con otra característica común a todos estos sistemas, el aislamiento. Esto se debe a que generalmente están relacionadas con las operaciones de lectura y una escritura. En este ejemplo, para leer el valor de la cuenta y luego cambiarla. Con el fin de mostrar una visión aislada de los datos de toda la transacción, incluyendo los registros que se van a leer pero no a escribir, debe ser bloqueado en los servidores de base de datos de muchos.
En Firebird, los lectores no ven el del escritor. Por ejemplo, cuando Bob y Jane leen los datos a ambos se les mostrará "versión 1", la lectura de 1.000 dólares. Cuando Bob haga cambios en la cuenta al hacer su retiro, los datos no se sobrescriben sino que una nueva "versión 2", esta vez con 500 dólares aparecerá. El intento de Jane de retirar 800 dólares fallará al encontrar que hay una nueva versión.
A este enfoque del control de concurrencia se le llama control de concurrencia multiversión. La aplicación Firebird de control de concurrencia multiversión comúnmente llama a su arquitectura multi-generacional. Firebird fue la segunda base de datos comercial en utilizar esta técnica, la primera fue diciembre 's Rdb / ELN.
El control de concurrencia multiversión también hace el aislamiento instantáneo de transacciones relativamente fácil de implementar. Una transacción con aislamiento instantáneo en Firebird muestra el estado de la base de datos precisamente en el instante en que la operación comenzó. Esto es muy útil para copias de seguridad de una base de datos activa , procesos de larga duración por lotes, etc.

Esos registros 'inservibles' no se borran, están ahí marcados como inservibles, su espacio será ocupado por cualquier otro. Sólamente con un backup/restore se eliminarán. También creo recordar que hay un parámetro en el comando gbak para eliminarlos. Pero no debes preocuparte por ellos, yo nunca he conocido ningún problema en ningún cliente, y es normal bases de datos entre 10 y 50 gigas, sin problemas, incluso algunos compañeros han comentado algo de clientes suyos con bases de datos mucho mayores.
Quiero decir con esto que no es un motivo de preocupación, que es sólo una característica, una forma de trabajar de firebird.


En relación al resto de tu comentario, puede que en tu caso te interese hacer commit cada vez, al igual que los cajeros bancarios.
Pero lo que yo te comentaba no era eso, sino el tener un sólo componente TIBTransaction (o como se llame) para todas esas transacciones, que no es necesario tener varios componentes de transacción, que uno sólo se encarga de todo.
Ahora bien, si te quedas más tranquilo poniendo más, pues nada, tampoco hay problema.

Y en cuanto al rendimiento, pues ya sabes, primero hay que hacer pruebas lo más realistas posible, antes de entregar nada al cliente.

Mira la entrada de Interbase en la wikipedia, lo dicho allí vale para Firebird.