Firebird AND Threads

[rastafarey]

buenos amigos yop uso ibo y jamas he tenido esos problemas.

[[Chris]]

Empezado por rastafarey

buenos amigos yop uso ibo y jamas he tenido esos problemas.

Como ya le había recomendado a rolandoj sería bueno que hiciera una prueba con componentes nativos para la conexión, hay que recordar que dbExpress adapta el Query para que sea compatible con la mayoría de las DBs.

[rolandoj]

Empezado por D&W

Como ya le había recomendado a rolandoj sería bueno que hiciera una prueba con componentes nativos para la conexión, hay que recordar que dbExpress adapta el Query para que sea compatible con la mayoría de las DBs.

Hola,

No creas que he olvidado tú sugerencia. Lo que pasa es que, para que pueda servirnos, sería necesario reemplazar todo lo involucrado, ya que no tendría sentido estar probando con unas queries vía dbExpress y otras IBO en la misma consulta. Son bastantes llamadas, luego, aún si me funcionara todo bien, lo único que probaría sería que el problema es con dbExpress; pero no me diría si es configuración de dbExpress o algún error en su código, y ni siquiera me localizaría el punto del problema.

Por lo anterior, no he probado por ese camino; pero, de todas formas agradezco la idea.

De hecho, la idea que tengo ahora es esperar a Oracle; pero, en el intermedio, revisar lo que se pueda, siempre y cuando no represente demasiado esfuerzo

Saludos

[rolandoj]

Hola,

Empezando a ver lo de la sección crítica, me encontré una referencia a su uso en DLLs, que es mi caso. Me asaltan muchas dudas, ya que no había encontrado antes ninguna observación al respecto, dentro de lo que he leído; así que le abrí un hilo. Pueden verlo aquí:

http://www.clubdelphi.com/foros/showthread.php?t=54254

El punto es que si la cosas son como dice la referencia que encontré, deberé recodificar la parte de actualización de variables globales (Por cierto, no olviden que eso no afecta al problema actual, ya que en las pruebas realizadas aún no hemos usado datos globales)

[rolandoj]

Hola,

El problema parece solucionado, aunque aún persisten algunas anormalidades.

Les adelanto que sí tenía que ver con drivers, aunque no exactamente un error en ellos. Les explicaré bien en cuanto solucione algunos detalles aún oscuros.

Ahora les pido colaboración a ver si alguién puede aclarar algo que encontré como parte de la investigación de este problema. Es un detalle que había manejado hace tiempo y lo había pasado por alto; pero que me genera dudas.

Le abrí el siguiente hilo :

http://www.clubdelphi.com/foros/showthread.php?t=54401

[rolandoj]

Hola,

Les cuento que las pruebas para aclarar los otros detalles me han llevado a un punto donde requiero ayuda.

Recuerdan mis dudas respecto a TCriticalSection ?. Eran porque la concurrencia también fallaba en casos en los que una de las llamadas no involucraba acceso a Bases de Datos. Pués bien, todo parece indicar que es más bien un limitante o un problema de configuración con Indy. Es un caso
que técnicamente puede servirle a algunos. Le abrí este hilo:

http://www.clubdelphi.com/foros/showthread.php?t=54448

[rolandoj]

Empezado por rastafarey

buenos amigos yop uso ibo y jamas he tenido esos problemas.

Hola,

Agradezco mucho el aporte; pero, yo necesito que mis programas sean portables entre motores de bases de datos, luego no me sirven los componentes IBO.

Por otra parte, con las últimas pruebas, me asaltan dudas de que el acceso a la Base de Datos no sea el único problema. Veamos:

Una de las pruebas extremas que hice fué encerrar todo el código de una consulta en una sección crítica, y, para mi sorpresa, se bloqueó. Complementé la prueba implementando mi propia sección crítica para garantizar que no se ejecutará otra consulta mientras se estuviera ejecutando una llamada; y me funcionó bien.

La conclusión que saco es que algo pasa con el manejo del componente TCriticalSection y, por razones que desconozco, permitió que se ejecutara algo en "simultánea". Averigué algo y al parecer hay aspectos "oscuros" en el tema. La explicación dada en las ayudas de Delphi, y usualmente encontrada en ejemplos, puede no ser tan completa como podría esperarse, ya que encontré notas donde alguién advierte de problemas relacionados con ella e incluso dice que los variable compartidas TList deben ser protegidas con una clase diferente a TCriticalSection. Vean esta página: http://www.gothi.co.uk/2006/10/threading-in-delphi.html

El tema me interesa porque, por eficiencia, se manejan un objeto global para datos caches con varias listas descendientes de TStringList. No hay riesgo de que afecten las pruebas hechas porque durante las mismas nunca se han usado las opciones que modifican datos globales. Alguién sabe de algún hilo donde se trate a fondo este tema, o puede abrir alguno para ilustrarlo ?

Lo importante de este caso es que me ha hecho pensar en la posibilidad que el problema no esté en el propio acceso a la Base de Datos. El código de estas consultas es muy complejo y quizás se están llamando algunas rutinas de librería Delphi que no son hilo seguro. No lo había considerado antes porque tenía entendido que lo que no era hilo seguro eran los componentes visuales, y este es un DLL que no los usa; pero, quizás hay otras unidades que no lo son. Alguién puede sugerir como revisar esta posibilidad ?