Firebird AND Threads

[Abel Garcia]

Hola A todos tengo un problema en el que espero puedan ayudarme.

Un dia intentando probar el Acceso a una base de Datos de Firebird, realice la siguiente prueba en la misma aplicación cree dos Threads los cuales se ejecutarían al mismo tiempo cada uno con un Query y una transacción diferente, los arranque los dos al mismo tiempo, y mi sorpresa es que la aplicación se queda completamente colgada cuando se encuentran los dos, ósea no hay error de la aplicación o de comparición de recurso solamente se queda colgada. Ok Esto se puede arreglar por medio de Secciones Criticas o Semáforos Etc. En este caso en particular de dos Threads.

Esta solo fue una prueba que me enseño lo que pasaba. Bueno el problema que tengo es: Tengo una aplicación la cual tiene solo un Thread el cual esta realizando operaciones de lectura y escritura periódicamente, mientras que el hilo principal de la aplicación se dedica a hacer otras cosas, un dia tube la necesidad de que esta aplicación vigilara la escritura de una tabla por medio de un evento de Firebird y realizara algo al momento de la escritura en dicha tabla.
por medio de IBX use el componente de Eventos y lo bote en la aplicación principal, ahora debido al funcionamiento de este tipo de componentes los cuales se cuelgan del hilo principal de la aplicación. Al momento de lanzar un evento como era de esperarse, se pone en conflicto con el Thread de esta misma aplicación y de la misma forma que se quedaba la primera aplicación que les mencionaba se queda colgada. ahora como puedo salvar este problema usando Secciones Criticas o
Semáforos, alguien sabe por que se suscita este problema cual es la causa.

[Casimiro Notevi]

seguramente estás usando la versión superserver, prueba con la classicserver y nos cuentas qué tal

[Abel Garcia]

Empezado por Casimiro Notevi

seguramente estás usando la versión superserver, prueba con la classicserver y nos cuentas qué tal

Hola que tal
Cual es mas o menos la Dif entre uno y otro, por que cres que esto prodria corregir este problema. Gracias

[Casimiro Notevi]

echa un vistazo a este enlace, quizás te sirva.

[rolandoj]

Hola,

Podrían comentar detalles de este problema ?. Tengo un problema similar que ya tiene mucho tiempo y sobre el cuál he venido trabajando un poco a ciegas, manejando las cosas a punta de prueba y error.

El escenario es el siguiente :

Tengo una aplicación, con un web server que es servidor ISAPI basado en WebBroker y un cliente Indy 8, ambos desarrollados inicialmente en Delphi 4, con BDE e Interbase 6, y Omnisecure como servidor.

Ese era un escenario prototipo para pruebas ya que al final estaremos con Oracle 10 (no lo tenemos aún disponible) y probablemente IIS

Las pruebas iniciales en ese escenario trabajaron bien.

Luego, por varios motivos, pasamos el escenario de pruebas a Delphi 2007 con dbExpress e Indy 10, y empezaron los problemas.

Concretamente, hay un problema de concurrencia, y esta aplicación si requiere soportar varios hilos simultáneos, por lo que el problema es preocupante.

Siguiendo algunos concejos, finalmente pasé a Firebird 2.0.3 SuperServer; pero el problema de concurrencia continúa. He aquí mis últimas pruebas:

1. Los hilos generados para ISAPI por la tecnología Webbroker parecen estar funcionando bien.

2. Cuando se accesa la Base de Datos, y los hilos son más o menos independientes (o sea, poco riesgo de que algunas operaciones colisionen), todo parece funcionar bien.

3. Cuando dos hilos accesan la Base de datos y sus operaciones internas trabajan frecuentemente sobre las mismas tablas, la aplicación se cuelga

4. Vale anotar que todo esto ocurre en un escenario de solo consulta; luego no existe la posibilidad de que una modificación en la Base de Datos pueda generar los problemas.

Estaba en camino de elaborar programas de prueba para analizar mejor el último caso, cuando me encontré este hilo que me hace suponer que definitivamente si hay problemas a nivel de las herramientas cuando se accesan simultáneamente las mismas tablas.

Aquí me aplican un par de preguntas:

1. El problema es el motor (interbase, firefird) ?

2. El problema es el driver dbExpress ?. Yo estoy usando el que viene para Interbase, supuestamente debería servir para Firebird.

Mucho agradecería si alguién pudiera documentar claramente esta situación.

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

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

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 ?