Foros Club Delphi

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   Conexión con bases de datos (https://www.clubdelphi.com/foros/forumdisplay.php?f=2)
-   -   deadlock en unas maquinas pero no en otras ??? (https://www.clubdelphi.com/foros/showthread.php?t=21782)

DobleSiete 27-05-2005 15:02:36

deadlock en unas maquinas pero no en otras ???
 
Estoy obteniendo el clásico mensaje de deadlock update conflicts with concurrent update en un programa hecho en Delphi 7 e InterBase 6.5 (usando componentes IBX y ADO)... pero mi caso es algo distinto.

Ya he leído bastante al respecto como para saber que es un problema de transacciones... lo que no entiendo es porque en tres máquinas de la oficina tengo ese error, pero en la máquina de mi casa núnca aparece, de hecho, funciona perfectamente bien... y cuando hablo del mismo programa me refiero a que lo copio de un sitio y lo corro en otro.

Gracias a todos por adelantado.

PD: Algo realmente curioso es que en la máquina donde el programa funciona bien (ejecutado desde el disco duro) obtengo el mensaje de deadlock cuando lo ejecuto desde una memoria flash USB (un zMate Pen de 256 MB). ¿Alguien podría darme un explicación de este fenómeno?

jachguate 27-05-2005 17:48:56

Hola DobleSiete.

Cita:

Empezado por DobleSiete
Estoy obteniendo el clásico mensaje de deadlock update conflicts with concurrent update en un programa hecho en Delphi 7 e InterBase 6.5 (usando componentes IBX y ADO)... pero mi caso es algo distinto.

A que te referis con que es algo distinto... ¿distinto de que?

Cita:

Empezado por DobleSiete
Ya he leído bastante al respecto como para saber que es un problema de transacciones... lo que no entiendo es porque en tres máquinas de la oficina tengo ese error, pero en la máquina de mi casa núnca aparece

¿Seguro de haber leido suficiente?

Claro que en la máquina de tu casa, si no hay actualizaciones concurrentes, pues el problema nunca se dará. (ver lo que he subrayado en el mensaje de error de la primera cita).

Si logras simular las actualizaciones concurrentes, seguro que el problema se dará nuevamente. Las técnicas para evitar este problema son, principalmente, hacer las transaccoines tan cortas como sea posible (por ejemplo, usando el caché de actualizaciones y volteando todo a la BD en unos cuantos milisegundos) y hacer que las actualizaciones se realicen en el mismo orden sobre los registros en todos los clientes, con lo que algunos quedarán esperando que finalicen las transacciones de otros, pero se minimiza la posibilidad de deadlocks.

No es normal que una sola aplicación cliente produzca deadlocks solita... siempre que uses una sola transacción dentro de la aplicación. Si hay varias transacciones abiertas, si que la aplicación sola puede hacerse el candadito.. :D


Cita:

Empezado por DobleSiete
Algo realmente curioso es que en la máquina donde el programa funciona bien (ejecutado desde el disco duro) obtengo el mensaje de deadlock cuando lo ejecuto desde una memoria flash USB (un zMate Pen de 256 MB). ¿Alguien podría darme un explicación de este fenómeno?

Sinceramente, no creo que tenga que ver con el origen del ejecutable... seguramente ha coincidido con que en esas ejecuciones ha habido concurrencia de actualizaciones.

Hasta luego.

;)

DobleSiete 30-05-2005 19:24:21

La unica diferencia que hay entre el funcionamiento del programa en la oficina y mi casa, es en la ubicación de los archivos DBF. En la oficina están en un servidor Novel NetWare, el acceso se realiza en la unidad M:, pero en mi casa debo simular esa unidad en mi maquina usando SUBST M: C:\DBF, apartando eso no hay diferencia...

Por que si fuese por que alguien más está tocando los DBF ¿por antes no tuve problemas? las consultas son simples SELECT a tablas relacionales, que se llenan en tiempo de ejecución con el contenido de los archivos dbase. Se supone que antes debería haber sucedido, pero no, no es el caso.

Creo que la causa del problema que se presento fueron dos ADOTable que leían la misma tabla, pero el asunto es que esto dos componentes eran llamados por dos eventos OnClick separados, así que no hay confusión que valga.


PD. como sea tuve que tomar una versión anterior (que funciona bien) y comencé a modificarla y compilarla poco a poco... pero el error no ha vuelto a repetirse... es más, el módulo ya está terminado y funciona a la perfección, que hice o no hice es la cuestión.

jachguate 30-05-2005 19:50:38

:confused:

ahora si que estoy confundido... en tu primer mensaje se leía:

Cita:

Empezado por DobleSiete
Estoy obteniendo el clásico mensaje de deadlock update conflicts with concurrent update en un programa hecho en Delphi 7 e InterBase 6.5

Y ahora...

Cita:

Empezado por DobleSiete
La unica diferencia que hay entre el funcionamiento del programa en la oficina y mi casa, es en la ubicación de los archivos DBF.
...
los archivos dbase

Mientras no sepamos de que estamos hablando exactamente... me parece imposible continuar con el tema... :mad:

DobleSiete 31-05-2005 16:00:47

Disculpa la confusión...

No quise hechar todo el cuento por que no me parecía necesario, pero ya veo que sí :-)

Los datos se encuentran en formato dBASE III en un servidor Novell NetWare, compartidos a través de la unidad de red M:\, el programa en Delphi 7 y la base de datos InterBase 6.5 se encuentran en la estación de trabajo.

¿Por que este enredo...? ¿Por que no usar IB y punto? muy simple, estamos en un periodo de transición, estamos pasando de Clipper 5.01 y dBase III a Delphi 7 e InterBase 6.5. Los datos siguen en los DBF del servidor y seguirán así por un tiempo, la base de datos IB almacena los datos temporalmente pues al entrar al modulo lo primero que se hace es borrar las tablas respectivas y llenarlas con los archivos DBF correspondientes. Para esto utilizo componentes ADO (para los DBF) y IBX (para InterBase).

Ahora mi pregunta es ¿cual de los dos componentes genera el mensaje deadlock? no recuerdo haber tocado propiedades de ningun componentes de acceso a bases de datos (ni ADO ni IBX). El modulo funcionaba bien y de buenas a primeras apareció el error... un error que ya no veo (el modulo está terminado y funciona perfectamente, pero tuve que retrocer).

Inclusive en fases de pruebas anteriores se ejecutaba el programa hecho en Clipper y el programa en Delphi, ambos en diferentes estaciones accesando a los mismos archivos DBF en la unidad M:\ del servidor NetWare, y funcionaba perfectamente bien. Por eso estaba asumiendo que el error estaba en los IBTable o en el IBDatabase

Estoy preguntando todo esto por que sería fatal que en el futuro volviera a aparecer el mismo error y me viese obligado a reescribir codigo.

jachguate 31-05-2005 17:21:10

Hola.

A mi manera de ver, el deadlock puede ocurrir en cualquiera de las dos conexiones, pero dudo que la de DBase te devolviera una excepción... seguramente se quedaría toda la vida esperando a que el deadlock dejase de existir (cosa que sabemos es imposible). Probablemente ADO daría un timeout... pero no lo he probado.

En ib/fb, por el contrario, el deadlock se reportará tan rápido como sea detectado por el motor. Para el futuro, creo que lo importante es que comprendas en que consiste el deadlock, pues este no se produce por si mismo... hay algo en la forma de operar el programa o en el propio código que lo produce y el motor de la base de datos no puede mas que simplemente reportarlo.

Hasta luego.

;)

DobleSiete 01-06-2005 15:12:58

Bueno... no me queda mas que estar pendiente, al menos tengo dos programas que hacen (casi) lo mismo. Tendría que revisar linea por linea, o propiedad por propiedad... pero al menos con tu explicación se que no son los componentes ADO (pues leen archivos DBF que no son muy comunicativos con los errores :-) deben estar con los IBX.

El asunto es buscar tiempo y juntarlo con algo de curiosidad ...

muchas gracias por la explicación.


La franja horaria es GMT +2. Ahora son las 22:05:23.

Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi