Transacciones en Zeos. Conviene una por Conexión ?

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

[rolandoj]

Empezado por Casimiro Notevi

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.

Hola Casimiro,

Gracias por el dato. Resulta interesante leer esa documentación.

Más allá de las obvias limitaciones de las pruebas, comentadas en ese hilo, me llama la atención la diferencia de Zeos con las otras tecnologías que soportan múltiples motores (no incluyo a las que solo trabajan con Interbase/Firebird porque es obvio que tenían que ser más rápidas).

El caso es que esa prueba muestra a Zeos como 4 veces más lento que dbExpress. Eso es preocupante y habría que hacer más pruebas para confirmar rendimientos. Es que incluso es el doble de la criticada BDE.

Bueno, como dije antes, creo que ya toca ponerse a probar de a poco.

Saludos

[[mightydragonlor]]

Empezado por rolandoj

Hola Casimiro,

Gracias por el dato. Resulta interesante leer esa documentación.

Más allá de las obvias limitaciones de las pruebas, comentadas en ese hilo, me llama la atención la diferencia de Zeos con las otras tecnologías que soportan múltiples motores (no incluyo a las que solo trabajan con Interbase/Firebird porque es obvio que tenían que ser más rápidas).

El caso es que esa prueba muestra a Zeos como 4 veces más lento que dbExpress. Eso es preocupante y habría que hacer más pruebas para confirmar rendimientos. Es que incluso es el doble de la criticada BDE.

Bueno, como dije antes, creo que ya toca ponerse a probar de a poco.

Saludos

Como dije antes, esto no se nota, a menos que hagas transacciones intensivas, de mas de 10.000, además, ZEOS tiene que hacer Parser de todas las consultas para identificar si es correcta o no, a parte de las múltiples interfaces a los diversos motores, cosa que ADO y BDE no hacen, por otro lado ZConnection1.ExecuteDirect(), ejecuta una instrucción SQL sin pasar por todo el proceso y es por mucho mas rápida a las normales, así que siempre tienes la opción, dependiendo del proceso que hagas, como en vez de generar 1000 inserts con 1000 commits, generas un sólo commit para los 1000 inserts y podrás ver una diferencia grande en desempeño.

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.

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

Hola Casimiro,

En general, el hacer simulaciones es una opción válida y recomendable. De hecho, y hasta cierto punto nosotros también las hacemos; pero, en mi caso hay dos problemas:

1. No conocemos ni el motor ni los equipos en que se ejecutaran los aplicativos. Eso sería lo de menos porque en últimas podríamos trabajar con equipos y motores representativos; pero, igual no resulta una prueba tan diciente.

2. El gran problema es la dificultad de armar una simulación razonable porque aquí se trata de un sistema muy complejo, con muchísimas tablas de características muy disimiles, relaciones entre ellas, y procesos mezclados, que no permiten facilmente identificar los cuellos de botella más críticos. Por eso es que he procurado indagar en la parte teórica de los rendimientos.

Como sea, creo que ya no hay mucho más que podamos analizar en la parte teórica y ya toca empezar a hacer pruebas.

Saludos

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