Transacciones en Zeos. Conviene una por Conexión ?

[rolandoj]

Hola a todos,

Investigando sobre Zeos me encontré con un tema que me sorprende. Es una pregunta para veteranos de Zeos; pero, como es igualmente clave para principiantes explicaré en detalle el concepto antes de preguntar:

Parte vital del trabajo normal que uno hace al grabar datos en una Base de Datos es la inserción, borrado y modificación de registros.

Por ejemplo, y típicamente, un documento está formado por un registro en una tabla maestra y múltiples registros hijos en varias tablas detalle. Por integridad de la información, bajo el principio de "todo se graba o no se graba nada", todos los registros de las diversas tablas involucradas se guardan bajo una sola transacción.

Eso, también usualmente, se hace entre dos puntos de código de nuestro programa con un comando Startransaction y un comando Commit, que suministra el componente de conexión a la base de datos. En el caso de Zeos ese componente es TZConnection.

Por tanto, la secuencia de trabajo con un componente TZConnection (u equivalente) debería ser :

Configurar los parámetros de conexión
Abrir la conexión (propiedad Connected a True)

Por cada ocasión en que se deba grabar un bloque de registros :

Invocar el método StartTransaction
Efectuar las operaciones de inserción, borrado y modificación de registros.
Invocar el método Commit
Si hay errores, invocar el método Rollback para restaurar todo al estado inicial

Finalmente, cerrar la Conexión (propiedad Connected a True)

Ahora viene la pregunta :

Según lo que leí, el método Commit en Zeos usa un "commit suave"; eso significa que los recursos que utilizó en el transcurso de la transacción, típicamente copias temporales de registros involucrados, no son liberados (al menos para el caso de Firebird que era el ejemplo que ilustraban). Esto implica que en tablas grandes, pasado algún tiempo, el rendimiento de la base de datos se degrada.

Para que los recursos temporales usados en una transacción se liberen, en Zeos, se requiere emitir un "commit duro", y ese comando solo lo emite en Zeos cuando se cierra la conexión

La conclusión que saco es que, para efectos de mantener un buen rendimiento, la metodología en Zeos sería que una vez abierta la conexión se iniciara una transacción y una vez terminada esta se cerrara la conexión; es decir, usar una sola transacción por conexión

Sin embargo, eso va en contravía del modelo tradicional de mantener abierta la conexión mientras se efectuan multiples transacciones. El modelo tradicional parte de que al abrir la conexión se colocan en cache una serie de recursos que posteriormente permite mayor velocidad en las operaciones.

Así las cosas, la gran pregunta es : Conviene en Zeos manejar solo una transacción por conexión, sacrificando el cache de inicio de conexión; o es mejor mantener el modelo tradicional, sacrificando el rendimiento directamente sobre la Base de Datos.

Ciertamente no es una pregunta facil. Será que alguien ha participado en discusiones de este tema ?. Alguien sabe de estadísticas a favor o en contra de eso ?.

Bueno, alguien puede confirmar la interpretación que hago al final ?. Es una traducción de un material escrito de manera algo vaga en Inglés y quizás estoy malinterpretando algo

[Casimiro Notevi]

Sí se ha hablado antes sobre este tema, a saber dónde.
En mi caso, y en el caso de otros muchos, tenemos sólamente un componente database y otro transaction. Así que todas las acciones con la base de datos pasan por un único componente transaction. No recuerdo cómo es con Zeos, pero con las IBX (por poner un ejemplo) son los componentes TIBdatabase y TIBtransaction. Todos los componentes dataset añadidos: query, tablas, etc. se enlazan con ese tibdatabase y el tibdatabase está enlazado con ese tibtransaction.
Lo que dices de "commit suave" es un "commitretaining".
Si has usado un cajero automático de los bancos, verás que si haces 2 transacciones seguidas, por ejemplo (te pregunta si vas a hacer otra transacción y le contestas que 'sí'), sacar 20 euros y después sacar otros 20 euros, verás que el sistema vuelve a empezar, saca la tarjeta de crédito/débito y la vuelve a insertar para iniciar la segunda transacción, o sea, que cierra por completo la transacción e inicia otra, no deja nada "a medias", eso es lo más seguro.
Pero como bien dices, en una gestión comercial, por ejemplo, es un método "laborioso" trabajar de esa forma. Por lo que normalmente no se hace en todas las ocasiones.
Lo que dices de firebird no es ningún problema, firebird trabaja con "versiones" de registros, no representa inconveniente alguno, es simplemente una forma de controlar las transacciones. Esos "registros inservibles" se limpian automáticamente, aunque también lo puedes hacer manualmente, basta realizar un backup/restore para que se desechen.
En mi caso, siempre instalamos un sistema de backup en los servidores firebird, para que se ejecuten por la noche, y dejan la BD limpia y reluciente para iniciar el siguiente día , son BD de muchos gigas y bastantes conexiones simultáneas, habitualmente, por lo que en un sólo día aumentan varios gigas.
Se hace el backup por seguridad, no porque ralentize el sistema.
El otro día un usuario (de clubdelphi) decía que tenía una BD de 10 gigas y que era algo lenta, le aconsejé hacer un backup/restore y volvió a la normalidad, además de ocupar menos de 400 megas, parece que nunca jamás había hecho "limpieza" de la BD
Te aconsejo que leas "EL" documento por excelencia sobre transacciones.

[rolandoj]

Hola Casimiro,

Veo que no estás muy seguro de como es usando Zeos; o sea, la limpieza es automática al hacer el commit ?. Según lo que yo había leído, el problema es que no se hace automáticamente hasta que se cierre la conexión.

En un entorno de servidor web, la conexión está permanentemente vigente hasta que se baje la librería. Según el tipo de aplicación, puede pasar mucho tiempo, incluso semanas, antes de eso, y el volumén de transacciones puede ser muy alto afectando el rendimiento.

Por otro lado, lo que dices de que es laborioso trabajar con Trabsacciones, es cierto en la medida de que el programador no haya establecido una buena metodología o herramientas de apoyo. En mi caso, eso es tema superado y siempre trabajamos, facilmente, con transacciones.

Y más allá de si se usa o no, el punto fuerte del tema es que se debería usar. Los programas que no lo hacen no están dando garantías razonables de integridad y consistencia en sus datos.

Por otro lado, buen dato lo del documento. Saqué algo de tiempo para leer un poco. Hasta donde voy son todas cosas que conozco desde hace años; pero, es largo, a lo mejor aparece algún dato nuevo para mi.

[Casimiro Notevi]

Creo que no me he explicado bien
Zeos lo conozco de hacer pruebas y poco más, lo que no entiendo es qué quieres decir con lo de "¿la limpieza es automática al hacer el commit?", no sé a qué limpieza haces referencia.

En cuanto a las conexiones abiertas por la web, que yo sepa, son configurables para que se desconecten pasado un tiempo determinado, por el propio servidor web.

Y en cuanto a lo que dices sobre "la laboriosidad en el tratamiento de las transacciones", no me refería a eso, me refería a que en una gestión comercial no puedes estar desconectando a los usuarios y volviendo a conectarlos cada vez que hagan una transacción de cualquier tipo, salvo que uses un esquema similar a un cajero bancario. O sea, que tienes que usar commitretaining en lugar de commit.

A ver si ahora me he explicado mejor

[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 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.

[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 Notevi]

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 Notevi]

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.

[ElMug]

Lo cierto es que commit es un comando SQL al que cada motor pude dar variantes de implementacion.

Aunque no uso Zeos, me atrevo a dudar eso de que "autocomit" este bajo el control de sus componentes.

En SQLite, por ejemplo, el modo AUTOCOMIT es default, pero si uno especifica BEGIN transaction el modo default se hace a un lado.

Commit retaining no se aplica a todas las bases de datos, al menos al nivel "motor". Inclusive, puede levantar error.

Diria que Zeos tal vez de resultados diferentes en diferentes bases de datos.

[Casimiro Notevi]

Empezado por rolandoj

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.

Entonces entiendo que te conviene usar commit "normal", lo que yo he llamado antes "modo de trabajo tipo cajero bancario"
Por lo que has explicado supongo que con los componentes Zeos tendrás que cerrar la conexión y volver a conectar de nuevo para lograrlo.

[rolandoj]

Empezado por Casimiro Notevi

Entonces entiendo que te conviene usar commit "normal", lo que yo he llamado antes "modo de trabajo tipo cajero bancario"
Por lo que has explicado supongo que con los componentes Zeos tendrás que cerrar la conexión y volver a conectar de nuevo para lograrlo.

Hola,

Efectivamente, a primera vista, cuando leí el artículo eso fué lo que pensé. Sin embargo, es precisamente porque, a luz de lo mencionado en el artículo, eso sería lo recomendable, es que hice la pregunta de este hilo, ya que eso implica que se pierde el caché de la conexión, tema que no fué discutido en el artículo y que también genera un handicap.

Es que para estar claros debemos considerar lo que yo explicaba del modelo Web. Aquí todo el acceso a la Base de Datos ocurre en el servidor. Los equipos clientes no saben de la Base de Datos. Eso marca una gran difererencia con programas que si tienen conexión desde el cliente.

En ese tipo de programas, la conexión está vigente hasta que un usuario cierra el programa. Eso normalmente ocurre varias veces en el día, y fuerza a los mecanismos de "hard commit", o el commit normal que venimos hablando.

Pero, en el modelo Web, más concretamente con ISAPI o módulos Apache, la situación es diferente porque es una sola librería del servidor la que da servicio a todos los usuarios. En consecuencia, el servidor la descargará automáticamente solo cuando haya pasado un tiempo determinado sin que ningún usuario haya accedido a la librería. Si la empresa es de las que opera 24 horas, es probable que tal situación no ocurra sino pasados varios días (incluso semanas) o en mantenimientos programados.

Bueno, lo que me queda claro es que ninguno de nosotros sabe de algún estudio que de consejos al respecto. Básicamente, los consejos en cada caso los está dando la experiencia que cada uno tiene.

Ahora, mal que bien, creo que el tema ha sido interesante e ilustra, sobre todo a principiantes que pudieran llegar a leer este hilo, aspectos importantes del manejo de conexiones a Base de Datos y la ejecución de transacciones. Para complementar, en un rato le contesto a ElMug y a mightydragonlor.

[rolandoj]

Empezado por ElMug

Lo cierto es que commit es un comando SQL al que cada motor pude dar variantes de implementacion.

Muy cierto. Vale agregar que, como en el caso de Zeos, las tecnologías de acceso pueden establecer variantes en la forma de aplicar un Commit a la Base de Datos; pero, limitadas a las disponibles en el motor.

Empezado por ElMug

Aunque no uso Zeos, me atrevo a dudar eso de que "autocomit" este bajo el control de sus componentes.

Formalmente tienes razón porque en últimas quién maneja el modo es el motor. Quizás la frase que puse "El modo autocommit es el modo de default del componente de conexión a la Base de Datos de Zeos (o sea TZConnection)" no está muy bien redactada.

Lo que pasa es son los componentes los que emiten los comandos al motor; por tanto, para efectos prácticos, el control lo tenemos es por medio de los componentes de acceso, ya que nosotros no nos comunicamos directamente con el motor.

Por ello, desde el punto de vista de uno como programador, el control del modo lo tenemos es con los componentes, en este caso el componente TZConecction de Zeos. Asì, cuando se inicia la conexión el motor está en modo autocommit y ello lo identifica el componente; luego el modo autocommit, como dije, es el modo de default en que se inicializa el componente, más allá de que su origen no esté en el componente sino en el motor.

Empezado por ElMug

En SQLite, por ejemplo, el modo AUTOCOMIT es default, pero si uno especifica BEGIN transaction el modo default se hace a un lado.

Y es lo mismo que venimos diciendo aquí porque es que BEGIN TRANSACTION es el comando en el motor; pero, desde programa ese comando lo emite un método del componente y concretamente el mètodo StartTransaction. Fijate que efectivamente es lo mismo porque hemos dicho que cuando se llama a StartTransaction se apaga el modo autocommit y solo se reactiva cuando se emite el Commit o el RollBack

Empezado por ElMug

Commit retaining no se aplica a todas las bases de datos, al menos al nivel "motor". Inclusive, puede levantar error.

Interesante observación. No lo he experimentado; pero, supondría que Zeos, cuando el motor no soporte Commit retaining, debe emitir un commit normel en su método Commit.

Empezado por ElMug

Diria que Zeos tal vez de resultados diferentes en diferentes bases de datos.

Eso si no debería ocurrir. Alguno tiene evidencia de que ocurre.?

[Casimiro Notevi]

De todas formas, pienso que antes de darle tantas vueltas al tema, lo que deberías hacer es una prueba, creas un programita que realice consultas, modificaciones,etc. con códigos aleatorios y lo ejecutas tantas veces como clientes piensas que puedes tener trabajando, vas incrementando "el ataque" al servidor y vas comprobando cómo se comporta este último, así te puedes quedar tranquilo... o no.

Yo siempre hago simulaciones de los sistemas para ver si van a trabajar bien, tanto en conexiones, tamaño de base de datos, memoria, etc.
Estas pruebas las hago con muchísima más carga que la máxima esperada para el sistema en cuestión, así puedo estar seguro de que responderá adecuadamente.
Una de las últimas pruebas fue lanzar 1000 conexiones simultáneas a un servidor suse linux con firebird classicserver, realizaba selects, updates y deletes aleatorios en distintas tablas de una BD con más de 100 Gigas de tamaño. La prueba se superó con éxito.
A partir de ahí estábamos seguros que el proyecto iba bien encaminado y nos pudimos concentrar en seguir trabajando sabiendo que no habría problema.

[rolandoj]

Empezado por 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.

Hola,

Gracias por el comentario. Aunque no es de este hilo, creo que vale pena anotar algo acerca del uso de los Stored Procedures (SP), o procedimientos almacenados, para evitar malos entendidos respecto a otros conceptos discutidos aquí

En tú caso, la ventaja no es, como anotas, asegurarse que todo se haga en una sola transacción. Eso igual puede garantizarse desde lenguajes de programación, con o sin SPs. La ventaja, dependiendo del modelo de acceso (ahora lo aclaro), es codificar una sola vez, ya que el código de los SPs lo puedes llamar desde cualquiera de los lenguajes de programación a los que te refieres. Si no se trabajara así, podría ser necesario hacer la codificación de un mismo proceso en más de un lenguaje de programación.

Ahora, cuando hablo del modelo de acceso me refiero a si un programa accede a tú Base de Datos vía servicio Web, o si lo hace con conexión directa a la Base de Datos desde un equipo cliente. En el segundo caso, si algunos de tús aplicativos trabajan así, entonces si te es clave usar los procedimiento almacenados porque en ese modelo no se permite que otros lenguajes usen el código del servdor ya que este está entremezclado con el del equipo cliente.

Mi caso es diferente. Yo uso muy rara vez procedimientos almacenados porque para mi es clave la portabilidad de motores de Base de Datos (y si los uso, debo tener también disponible una versión alternativa sin ellos). La ventaja mayor que obtengo con los SP es de rendimiento; por ello los uso solo cuando mi codificación normal está dando malos tiempos de respuesta.

Los SPs no son portables porque cada motor tiene su propio lenguaje. Eso es una desventaja inaceptable en mi caso porque, como dije, me es muy importante que los clientes puedan elegir un motor de Base de Datos, entre un grupo lo más grande posible de motores disponibles. Así, cuando uso SPs, de todas maneras dejo una versión sin SPs para poder cambiar facilmente de motor si fuere requerido.

En el modelo Web. dado que no hay un equipo cliente conectandose directamente al motor, puede trabajarse usando cualquier lenguaje en el lado servidor y aún así soportar múltiples lenguajes del lado del cliente. Eso si, para ello, hay que usar el siguiente flujo de datos :

a. Petición enviada desde el cliente, mediante un protocolo y en forma de una cadena de texto
b. Decodificar los parámetros de la cadena
c. Efectuar las operaciones indicadas en la petición y, si es del caso, devolver una respuesta "pura" (eso es solo datos que se hubiesen generado)
d. Formatear la respuesta según el lenguaje que la pida (esta es la parte clave porque si es para desplegar páginas Web el texto varía según el lenguaje)
e. Devolver el resultado al cliente

Por eficiencia (evitar análisis del lenguaje de programación a tiempo de ejecución), lo mejor es encapsular en librerías (que serían realmente las compartidas), la lógica de negocios del punto c. (y probablemente también el punto b.)

De esa forma, se presenta un font-end de acceso a las librerías, que se codificaría distinto para cada lenguaje que requiera el servicio.

Aún se puede optimizar más; pero, ya esto parece curso de programación y nos alejamos del tema, así que mejor lo dejamos hasta aquí. Solo quise hacer la aclaración para evitar malos entendidos respecto a los SPs

Para finalizar, me preocupa lo que dices de que Zeos es el más lento de las tecnologías de acceso. Hay un hilo de discusión al respecto?

[Casimiro Notevi]

Empezado por rolandoj

Para finalizar, me preocupa lo que dices de que Zeos es el más lento de las tecnologías de acceso. Hay un hilo de discusión al respecto?

Sí que lo hay, se ha comentado en diversas ocasiones, aunque lo más a mano que tengo es esta comparativa del que hice un pdf.

También puedes ver este hilo.