Transacciones en Zeos. Conviene una por Conexión ?

[rolandoj]

Hola Casimiro,

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.

Ciertamente, el modelo Web, basado en librerías (otra cosa serían los ejecutables CGI), parte de que esas librerías permanecen en memoria, a fin de optimizar el acceso a las mismas.

Cuando pasado algún tiempo, configurable en el sistema, esas librerías, que están en memoria, no han recibido nuevas peticiones, el servidor Web las descarga de la memoria, operación que, lógicamente, cierra la conexión a la Base de Datos.

En el entorno más común, eso significa que en la práctica hay al menos una descarga de memoria al día. Sin embargo, en empresas que tengan producción de 24 horas, y/o operaciones con países de un uso horario distinto, es posible, dependiendo de la frecuencia de las operaciones, que pasen días o incluso semanas, sin que se descarguen las librerías. Son entornos en los que se hace necesario un frecuente manteniemiento programado.

Si las susodichas empresas tiene altos volumenes de operación, es claro que el rendimiento se degradaría más rápido.

De ahí mi pregunta, porque el tema sería de estadísticas : Hay estudios que confronten esa penalidad vs la penalidad de estar abriendo y cerrando la conexión por cada transacción.

Ten en cuenta que el modelo Web, que yo manejo, no opera como trabaja la mayoría de la gente. Todo el control transaccional existe solo en el servidor. El cliente no sabe nada de la base de datos y menos de transacciones.

Cada petición del cliente al servidor, si contiene alguna adición, modificación o borrado de datos. se hace en una sola transacción. Por lo anterior, en mi caso, adoptar el esquema de una conexión por transacción es programáticamente trivial, algo de minutos.

La razón es que solo tendría que modificar la macrorutina que responde a cada petición para abrir la conexión a la base de datos, hacer las tareas que hacía antes y cerrar la conexión al terminar.

En otras palabras, reubicar la apertura de la conexión, que actualmente hago a la carga de la librería, y el cerrado (actualmente en el descargue de la librería), para ponerlos en la macrorutina.

El problema pués no es de dificultad de programación sino de rendimientos. Hay que ver si se consigue mayor información

[Casimiro Noteví]

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.

[ElMug]

La limpieza de las bases de datos, es propiedad de la maquina o motor, y en mi limitado parecer, no es parte de comandos SQL. Eso ya va como "meta-comandos".

Es similar a "defragnentar", y asi como menciona Casimiro, es proceso usualmente postergado, pues obviamente estar barriendo continuamente bajaria el rendimiento ante el uso cotidiano.

Las bases de datos tipo mamuth, corren simultaneamente muchos servicios, y uno de esos, o varios, es/son la desconexion para liberar recursos, independientemente de lo que el cliente hace. Como lo hacen, ya son secretos de estado.

Mas de una transaccion abierta obviamente baja el rendimiento al usuario, pues le da mas carga al motor al tener que estar revisando lo postergado.

Cro que lo mas simple y completo es preferible. Cuando se cierra una transaccion, el cliente, para el motor, sigue alli. No creo que para Firebird sea diferente.

[rolandoj]

Hola a todos,Perdón por la demora. Me ocuparon en otras cosas y me tocó dejar el tema de lado.Empiezo con una observación de metodología. Efectivamente, el componente que uso para Transacciones es uno solo para todas, ya que es el mismo componente de conexión a la Base de Datos. Simplemente que en cada hilo una transacción se inicia y se cierra de manera totalmente independiente de cualquier otra que esté ocurriendo en otro hilo.El borrado físico de los registro inservibles, que yo sepa y como dice Casimiro, se da solo cuando hacemos las operaciones de BackUp/Restore. Eso se evidencia porque se disminuye el tamaño de la Base de datos al hacerlo. Ese proceso, como plantea ElMug es realmente una "defragmentación" de la Base de Datos; no solo para ahorrar espacio sino para reubicar datos de tal forma que los accesos de lectura sean más eficientes.Ahora bien, cuando se marcan como inservibles y se pueden reusar los registros temporales ?. Yo siempre había pensado, como dicen ustedes, que eso era hecho al fin de cada transacción; entre otras cosas porque lo lógico es que si ya la transacción fué exitosa, se liberen los recursos. Especialmente porque al poder reusar esos espacios el crecimiento de la Base de Datos es menor, favoreciendo el rendimiento.Sin embargo, el artículo que leí es el que me ha metido la duda porque si eso sigue así, como afirman ustedes y aparentemente dicta la lógica, a que se refieren los del artículo ?. No me puedo imaginar otro tipo de recurso que no se libere en el commit suave (o commit retain) y que pueda afectar el rendimiento de la Base de Datos tamto como ellos advierten.Si a ninguno se le ocurre una explicación, hay que pensar que, o bien los del artículo están equivocados, o hay algo que nosotros no sabemos.

[Casimiro Noteví]

Empezado por rolandoj

Especialmente porque al poder reusar esos espacios el crecimiento de la Base de Datos es menor, favoreciendo el rendimiento.

Creo que te estás preocupando por algo que "piensas que puede ser un problema", cuando realmente no lo es.

Y en cuanto al artículo que dices... ¿qué artículo es?
Y otra cosa ¿qué es eso de commit suave?

Yo puedo hablarte de mi experiencia y la de otros compañeros que han contado la suya aquí, y entre ellos nadie ha contado ningún problema con lo que tú estás contando de que pueda ser un problema. Olvídate del tamaño de la BD, el mismo rendimiento tiene con 5, 20, 50 gigas (mi experiencia), que con 70 gigas (experiencia de alguien que lo comentó en clubdelphi), como ese hospital ruso del que hemos hablado en alguna ocasión que quitaron oracle y pusieron firebird y su BD firebird ocupa más de 1 Tera.

[rolandoj]

Empezado por Casimiro Notevi

Creo que te estás preocupando por algo que "piensas que puede ser un problema", cuando realmente no lo es.

Y en cuanto al artículo que dices... ¿qué artículo es?
Y otra cosa ¿qué es eso de commit suave?

Yo puedo hablarte de mi experiencia y la de otros compañeros que han contado la suya aquí, y entre ellos nadie ha contado ningún problema con lo que tú estás contando de que pueda ser un problema. Olvídate del tamaño de la BD, el mismo rendimiento tiene con 5, 20, 50 gigas (mi experiencia), que con 70 gigas (experiencia de alguien que lo comentó en clubdelphi), como ese hospital ruso del que hemos hablado en alguna ocasión que quitaron oracle y pusieron firebird y su BD firebird ocupa más de 1 Tera.

Hola Casimiro,

Mira que tienes razón. Debimos empezar por ahí. Se me pasó y nadie lo preguntó antes. El artículo es el siguiente :

http://es.scribd.com/doc/84454450/A-...y-for-Firebird

Traduzcanlo ustedes mismo a ver que piensan. Como dije, quizás estiy traduciendo algo mal.

Ahora, lo he vuelto a leer con cuidado, y ahora tengo más dudas que antes. La frase clave era para mi :

"opening a new transaction with all the data and resources (especially the resultset) of the "old" transaction".

Porque, según lo escrito después, yo interpreto que los recursos son básicamente los registros internedios requeridos por la transacción; es decir, que en esencia el mecanismo lógico de "recolección de basura", no trabaja cuando se usa el método Commit de Zeos, (o sea, emitir un comando commit "soft" como dicen ahí). Y pienso que se refieren al mecanismo lógico porque, como hemos dicho antes, creo que todos estamos de acuerdo en que el mecanismo físico se hace es en las operaciones de backup/restore

Bueno, no se, lean todo el artículo con cuidado a ver que traducen ustedes

[Casimiro Noteví]

Ya veo, pero ahí habla de los 2 "principales" tipos de commit, el commit "normal" y el commitretaining. Lo que dice es que el zconection de zeos usa siempre el commitretaining (lo que ellos llaman "commit suave").
La diferencia que explica es que realmente commitretaining no cierra la transacción, por eso van "acumulándose", pero también dice que se cierran y liberan cuando cierras el programa... o cuando hagas commit normal, lo que en ese documento llama "commit duro"

Básicamente es lo que hemos comentado antes, debes plantearte cómo va a ser tu programa, si es estilo "cajero bancario" entonces commit y punto. En caso contrario debes hacer commitretaining.

Resumiendo:
El commit finaliza la transacción y evidentemente el dataset asociado también se cierra.
El commitRetaining confirma la transacción, se guardan en la BD los datos, pero no cierra la transacción sino que la mantiene activa, por lo que el dataset se queda abierto para que se pueda hacer nuevos cambios con la misma transacción.

No debes tener ningún problema por usar el commitRetaining, yo sólo uso commitretaining durante la ejecución de los programas, hasta que finalmente cierro todas las transacciones y la BD cuando salgo del programa, por lo que (si quieres) en ese momento puedes usar un commit por si tienes alguna transacción pendiente. Aunque, ya digo, jamás he tenido ningún problema de ningún tipo usando solamente commitretaining.