Firebird AND Threads

[rastafarey]

Me parece que el problema lo tienes en la configuracion de las transacciones. O estas usando el suwt wait o noreadversion.

Por que si tienes configurado ReadVersion,commited,nowait.

Es servidor no se que da esperando por que otra transaccion termine.

Es mas si es un simple y mortal select menos qu emenos te daria ploblema.

Con decirte qeu si configuras bien las transacciones no veras jamas ni el gfamoso abrazo mortal (deadlock).

Ya que la data afecta sera la ultima guarda asi se ejecuten los dos al mismo tiempo. debido a que el procesador solo puede ejecutar un proceso a la ves (atomicamente).

Ahora no se si tu equipo tine doble procesador y estas trabajkando con una version d efirebird que tenga soporte para varios procesadores.

[rolandoj]

Empezado por rastafarey

Me parece que el problema lo tienes en la configuracion de las transacciones. O estas usando el suwt wait o noreadversion.

Por que si tienes configurado ReadVersion,commited,nowait.

Es servidor no se que da esperando por que otra transaccion termine.

Es mas si es un simple y mortal select menos qu emenos te daria ploblema.

Con decirte qeu si configuras bien las transacciones no veras jamas ni el gfamoso abrazo mortal (deadlock).

Ya que la data afecta sera la ultima guarda asi se ejecuten los dos al mismo tiempo. debido a que el procesador solo puede ejecutar un proceso a la ves (atomicamente).

Ahora no se si tu equipo tine doble procesador y estas trabajkando con una version d efirebird que tenga soporte para varios procesadores.

Hola,

Ante todo, muchas gracias por los comentarios. Tengo unas dudas a ese respecto; pero, independientemente de ellas, no veo por qué la configuración de transacciones pueda incidir en mi problema.

Resulta que el bloqueo está ocurriendo en consultas. No hay nada que, ni siquiera indirectamente, implique modificar la Base de Datos. No se inicia explícitamente ninguna transacción desde el programa, ni hay riesgo que durante esas pruebas alguien invoque otro proceso que involucre el arranque de una transacción.

Lo otro sería que exista algún manejo automático de transacción por parte del motor o el driver; pero si es así, escapa a mis conocimientos al respecto.

Eso me conduce a la dudas que mencioné. Los parámetros de configuración a que te refieres no los encuentro, ni a nivel del servidor vía IBOConsole ni a nivel del componente TSQLConnection de dbExpress. Como los configuras ?. Yo pensé que eran manejo automático de dbExpress. Acaso es necesaria una herramienta distinta a IBOConsole ?.

Esa parte me interesa porque aún no hemos empezado pruebas intensas sobre transacciones.

Muchos gracias por todo

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