Transacciones en Zeos. Conviene una por Conexión ?

[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