Transacciones en Zeos. Conviene una por Conexió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.

[[mightydragonlor]]

Yo personalmente uso ReadCommited, no me ha presentado ningún problema, por el momento, además que también las transacciones las manejo directamente en los SP's, ya que a la base de datos pueden acceder diversos aplicativos, no sólo los que yo haga en Lazarus, sino Servicos Web y Páginas Web, en diferentes lenguajes, así que de esta forma me aseguro que todo se haga en una única transacción, especialmente cuando se intervienen varias tablas en una única llamada a un SP, por lo demás no veo ningún problema, es verdad que Zeos es el mas lento de los componentes de acceso a datos, pero no es algo que puedas medir en la experiencia de usuario, bueno, si, pero sólo si un usuario está haciendo miles de transacciones por segundo, lo notará, de resto no.

Saludos.

[rolandoj]

Empezado por Casimiro Notevi

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.

Hola Casimiro,

Bueno, según mi traducción, conceptualmente ese punto no es exactamente así; aunque para efectos prácticos es más o menos lo mismo.

Para ser claros, yo entiendo es que, en el caso de transacciones explícitas (que es siempre mi caso), las tecnologías de acceso (como BDE, dbExpress, etc), usualmente emiten un Commit normal que cierra la transacción y libera enseguida los recursos asociados. Eso es lo que yo hecho toda la vida.

Sin embargo, el método Commit de Zeos no emite un commit normal sino un comando "Commit Retaining" el cual hace básicamente lo mismo; pero, no libera los recursos. Es decir; si cierra la transacción. Lo que pasa es que inmediatamente abre una nueva transacción para la cual los recursos que se usaron en la anterior están "vivos", o sea utilizables en esta nueva.

En Zeos, según dicen ahí, el commit normal no se ejecuta a voluntad con un método propio, sino que es efectuado automáticamente cuando se cierra no una tranascción sino una conexión a la Base de Datos.

Por eso es que la interpretación que hice al inicio fué que, para optimizar ese aspecto, tocaba tener una sola transacción por connexión. En otras palabras, que una vez hecho Connected a True se debe llamar a StarTransaction, y tan pronto se haga el Commit (o el Rollback) poner Connected a False.

Por ende, dado que eso implica perder el cache de la conexión, pregunté si había estudios que sugieren que era mejor de hacerse (o si daba lo mismo), entre perder rendimiento usando múltiples transacciones por conexión, o perder el caché de conexión usando una transacción por conexión.

Vale anotar algo para los que tengan problemas de tradución del original. El modo autocommit es el modo de default del componente de conexión a la Base de Datos de Zeos (o sea TZConnection). En el modo autocommit, cada operación sencilla (Insert, update, etc) es implícitamente una única transaction.

En la práctica, no debería trabajarse nunca con este modo, a menos que se sepa que se va a actualizar un registro cuyos cambios no afectan a ningún otro registro de ninguna tabla de la Base de Datos. De lo contrario, sería frecuente que aparecieran datos inconsistente.

En lugar de eso, debería usarse el modo explícito; el cual es invocado por StarTransaction, invocación que por supuesto apaga el autocommit. Eso si, debe tenerse en cuenta que cuando la transacción explícita termina, también se reactiva automáticamente el modo autocommit.