Firebird AND Threads

[xander]

Nop, no es el Firebird... yo ya pasé por estas mismas, y no es el firebird ni las transacciones el problema, sino los componentes que usas para conectarte... el mismo problema tendrán quienes quieran montar una web con estos, en cuanto dos usuarios solicitan información al mismo tiempo el servidor se bloquea.

Generalmente ni IBO, ni IBX, ni FIBPlus estan pensados para trabajar con multiples hilos en paralelo usando sus mismos recursos... los únicos componentes que encontré que funcionan bien en ese ambiente son los UIB son los únicos ThreadSafe que conozco.

These components are "Thread-Safe" with any version of Interbase, FireBird and Yaffil and are working with Delphi, BCB, Kylix, Lazarus & FPC (Win32, Linux, FreeBsd).

[rolandoj]

Empezado por xander

Nop, no es el Firebird... yo ya pasé por estas mismas, y no es el firebird ni las transacciones el problema, sino los componentes que usas para conectarte... el mismo problema tendrán quienes quieran montar una web con estos, en cuanto dos usuarios solicitan información al mismo tiempo el servidor se bloquea.

Generalmente ni IBO, ni IBX, ni FIBPlus estan pensados para trabajar con multiples hilos en paralelo usando sus mismos recursos... los únicos componentes que encontré que funcionan bien en ese ambiente son los UIB son los únicos ThreadSafe que conozco.

Hola,

Muchas gracias por la información.

Es un dato muy útil; pero, en este caso específico, no estoy usando ninguno de ellos. Yo trabajo con dbExpress. Tengo dos razones :

1. Por metodología, nunca trabajo con componentes específicos a una base de datos. Mi filosofía es que las aplicaciones deben ser portables, cambiar de motor debe ser tan fácil como cambiar un "Alias" a la base de datos, a lo sumo, en casos extremos, algún cambio mínimo en el código. En este caso en particular, es aún más cierto porque Firebird, y previamente Interbase, son ambientes de prueba. La versión de productivo estará en Oracle 10, y, por razones ajenas a mi voluntad, aún no dispongo de Oracle para tener un ambiente de pruebas ahí.

2. Siempre he usado BDE; pero al cambiar a Delphi 2007, parte de las razones fué porque se nos habló mucho de un superior rendimiento de dbExpres, algo de lo que aún no tengo evidencia. Lo anterior para decir que tengo poca experiencia con dbExpress.

Ahora, en vista de tú comentario, me asalta una duda que ya he expreasdo en otros hilos. El driver dbExpress para Interbase/Firebird es hilo seguro ?. No he encontrado nada concreto al respecto; pero, a estas alturas uno debería esperar que sí. De tú comentario, deduzco que no lo es. Es un hecho que tienes confirmado ?

Una vez más reitero las gracias

[jachguate]

Empezado por xander

Generalmente ni IBO, ni IBX, ni FIBPlus estan pensados para trabajar con multiples hilos en paralelo usando sus mismos recursos... los únicos componentes que encontré que funcionan bien en ese ambiente son los UIB son los únicos ThreadSafe que conozco.

Hola xander.

Doy testimonio de haber usado IBX en aplicaciones multihilo contra firebird 1.5 y superiores, sin mayores contratiempos.

Un saludo.

[rolandoj]

Empezado por jachguate

Hola xander.

Doy testimonio de haber usado IBX en aplicaciones multihilo contra firebird 1.5 y superiores, sin mayores contratiempos.

Un saludo.

Hola.

Muchas gracias por la participación.

Quiero remitirme a la primera nota que he escrito en este hilo. Como puedes apreciar, el problema no es genérico. Al parecer ocurre bajo ciertas circuntancias que no he podido determinar con exactitud, aunque sigo acotándolo a medida que diseño más programas de prueba.

Pudiera ocurrir que exista algún problema que se dispara solo bajo ciertas circunstancias. Las consultas donde tengo el problema conforman un proceso muy complejo que incluye queries multitablas, y me viene a la mente uno de los primeros problemas que he tenido con Delphi 2007 y dbExpress : La necesidad de darle nombre explícito a campos Sum() o Count(), o constantes, en consultas.

Eso es un error particular. Quizás algo de eso está ocurriendo y por ello a unos les ha funcionado bien y a otros no.

Muchos saludos

[[Chris]]

A forma de opinión.

Concuerdo con rastafarey.
Ahora recuerdo. Cuando estaba iniciando el proceso de migración a Firebird, estove provando la configuración de las transacciones, en ese momento eran algo nuevo para mí, porque hasta entonces solo había trabajado con motores DB basados en archivos. No recuerdo exactamente que configuración era exactamente, pero había una que no me dejaba que dos hilos consultaran una misma tabla al mismo tiempo, el segundo siempre se quedaba colgado hasta que el otro terminara de "ver" los datos.

rolandoj, a mi también me costó creer que una tonta configuración en la transacción pudiera impedir que dos clientes puedan visualizar una tabla al mismo tiempo. No sé si a algún compañero le ha pasado, pero es cierto, no estoy inventando.

Ahora, lo de configurar la transacción con dbExpress, no tengo ni idea.

Empezado por rolandoj

Hola,
1. Por metodología, nunca trabajo con componentes específicos a una base de datos. Mi filosofía es que las aplicaciones deben ser portables, cambiar de motor debe ser tan fácil como cambiar un "Alias" a la base de datos, a lo sumo, en casos extremos, algún cambio mínimo en el código. En este caso en particular, es aún más cierto porque Firebird, y previamente Interbase, son ambientes de prueba. La versión de productivo estará en Oracle 10, y, por razones ajenas a mi voluntad, aún no dispongo de Oracle para tener un ambiente de pruebas ahí.

Puede que tengas cierto punto de razón, pero que tan a menudo uno cambia el motor DB de su aplicación. Creo que primero deberías de verlo por el lado del valance, entre tu productividad y la calidad de tu sistema.

Saludos.

[rolandoj]

Empezado por D&W

A forma de opinión.

Concuerdo con rastafarey.
Ahora recuerdo. Cuando estaba iniciando el proceso de migración a Firebird, estove provando la configuración de las transacciones, en ese momento eran algo nuevo para mí, porque hasta entonces solo había trabajado con motores DB basados en archivos. No recuerdo exactamente que configuración era exactamente, pero había una que no me dejaba que dos hilos consultaran una misma tabla al mismo tiempo, el segundo siempre se quedaba colgado hasta que el otro terminara de "ver" los datos.

rolandoj, a mi también me costó creer que una tonta configuración en la transacción pudiera impedir que dos clientes puedan visualizar una tabla al mismo tiempo. No sé si a algún compañero le ha pasado, pero es cierto, no estoy inventando.

Ahora, lo de configurar la transacción con dbExpress, no tengo ni idea.

Puede que tengas cierto punto de razón, pero que tan a menudo uno cambia el motor DB de su aplicación. Creo que primero deberías de verlo por el lado del valance, entre tu productividad y la calidad de tu sistema.

Saludos.

Hola,

Muchas gracias por los comentarios.

Lo que dices de las transacciones apoyando a rastafarey., me deja preocupado. La filosofía de una transacción es que se debe usar para impedir que alguién modifique (o incluso consulte, dependiendo de como estén configuradas), los datos protegidos en la misma.

Si, como tú estás confirmando, una configuración de transacción bloquea las simples consultas simultáneas, a pesar de que no hay una transacción explícita en progreso, el asunto es para pensarse. Ahora bien, en las pruebas que he hecho, eso no parece estar ocurriendo. El problema parece ocurrir con consultas complejas, aunque aún no puedo confirmarlo al 100%.

Adquiere más importancia entonces saber como hacer esa configuración para la combinación Firebird/dbExpress

Por último, en mi caso es relativamente frecuente el uso de diferentes motores de Bases de Datos, entre otras cosas porque trabajo independiente con varios clientes. De todas formas, aún si ese no es el caso, recomiendo fuertemente usar metodologías de portabilidad por el ahorro que representan para el cliente.

Una de mis mejores experiencias fué cuando una aplicación grande y vital, que tengo para una empresa importante, la pasaron de Oracle a SQL - Server. La tengo con BDE y solo necesité cambiar el Alias de la Base de Datos en el BDE, no se requirió ni una línea de código extra.

Michos saludos

[[Chris]]

rolandoj, la configuración que mencioné algún proposito debe tener (mantenimiento por ejemplo), no es la predeterminada, que a como dije, llegué a ella traveseando con la configuración. No vayas a pensar que Firebird es un mal e inepto servidor.

Por otro lado, dices que sospechas que puede ser por la complejidad de la consulta, si tuvieras que darle una escala del 1 al diez, que le darías? Intenta ejecutar la consulta al mismo tiempo en dos o más clientes distintos exactamente al mismo tiempo, que notas en el tiempo de respuesta, hay un margen claro y constante? Por otro lado, los hilos de ejecutan en la misma PC? porque también el problema lo puede causar dbExpress. Haz la prueba que te digo en distintas PC* y fijate en todos los detalles, haz la consulta en parte y ve donde está el cuello de botella.

Por otro lado, te aconsejaría que hagas pruebas con componentes nativos, como IBX o MDO. Puede ser que este tipo de puebas te ayuden a encontrar donde puede estar tu problema.

* Recuerda:

Empezado por rastafarey

... el procesador solo puede ejecutar un proceso a la ves (atomicamente).

Saludos.

[rolandoj]

Empezado por D&W

rolandoj, la configuración que mencioné algún proposito debe tener (mantenimiento por ejemplo), no es la predeterminada, que a como dije, llegué a ella traveseando con la configuración. No vayas a pensar que Firebird es un mal e inepto servidor.

Por otro lado, dices que sospechas que puede ser por la complejidad de la consulta, si tuvieras que darle una escala del 1 al diez, que le darías? Intenta ejecutar la consulta al mismo tiempo en dos o más clientes distintos exactamente al mismo tiempo, que notas en el tiempo de respuesta, hay un margen claro y constante? Por otro lado, los hilos de ejecutan en la misma PC? porque también el problema lo puede causar dbExpress. Haz la prueba que te digo en distintas PC* y fijate en todos los detalles, haz la consulta en parte y ve donde está el cuello de botella.

Por otro lado, te aconsejaría que hagas pruebas con componentes nativos, como IBX o MDO. Puede ser que este tipo de puebas te ayuden a encontrar donde puede estar tu problema.

* Recuerda:


Saludos.

Hola,

Muchas gracias por todo el apoyo.

Empiezo diciendote que las pruebas se han hecho con consulta simultánea desde dos PCs distintos a un servidor. Se trata de PCs ubicados en sitios físicamente distintos al servidor y con proveedores de Internet distintos. Claro está, desde ambos PCs, cuando no hay simultaneidad, o se trata de consultas que usan tablas distintas de la Base de Datos, o las mismas; pero en eaquemas relativamente simples (una tablas y pocas condiciones), trabaja bien; incluso, en la propia consulta del problema parece trabajar cuando el nivel de complejidad no está en sus máximos niveles.

Me explico mejor para que visualices la complejidad:

Estas consultas son creadas dinámicamente desde una interfase de usuario que permite escoger los campos a incluír (potencialmente cerca de 100) y las condiciones a colocar (algo así como un SQL guíado; pero el usuario no vé nada que parezca un lenguaje). Las condiciones también pueden ser numerosas; pero no tanto, aunque algunas condiciones pueden tener varios anidamientos. Dependiendo de los campos y las condiciones a incluír, se pueden ir agregando tablas a la consulta, generando bastantes uniones, e incluso otras complejidades de filtros que no pueden incluírse directamente en el Where, todo esto dinámicamente. A lo anterior, agrega que hay algunas consultas adicionales independientes que complementan el Query principal

Darle una calificación puede ser dificil; pero, dado que no se incluyen clausulas Group By o Having, yo lo pondría en 8, máximo 9

En cuanto al cuello de botella, cuando estas consultas se ejecutan solas, pueden tardar entre 10 y 20 segundos. Cuando se presenta el bloqueo, he llegado a esperar 20 minutos y siguen bloqueados. Eso podría hacer pensar en un cerrojo mortal; pero no veo por qué, dado que no hay transacciones explícitas.

Todo esto me lleva a una pregunta adicional. Hay alguna herramienta para monitorear problemas multihilo ?. Porque aquí el inconveniente es que siendo el código tan complejo, conteniendo en sí mismo varias Select, no conozco una manera de poder decir: el bloqueo se presenta al ejecutar la instrucción XXX.

Lo más lógico que pienso en este momento es que ocurre en la consulta más compleja del código; pero, no podría asegurarlo totalmente.

Muchos saludos