Transacciones y parámetros

[sur-se]

Hola. He realizado un pequeño programa de prueba en Delphi 5 contra Firebird 1.03 utilizando IBX. El programa tiene un timer al que se la asigna un tiempo aleatorio (entre 1 y 3 segundos) de forma que en el evento del timer se produce el siguiente proceso:
1) Parar el timer
2) Iniciar transacción
3) update de un campo de unas tablas (se hace campo=campo+valor)
4) Aceptar transacción
5) Asignar un tiempo aleatorio al timer
6) habilitar el timer de nuevo.

La transacción tiene puestos los parámetros por defecto. Ejecuto el programa en varios ordenadores a la vez y obtengo al poco tiempo el error Deadlock. conflicts with concurrent update. En teoría este error no debería darlo, pues si se encuentra un recurso bloqueado durante una transacción debería hacer un "wait".
Suponiendo que no lo hace así, edito las propiedades de la transacción y le especifico los valores consistency y wait, para que haga las esperas. Lanzo la aplicación y obtengo el mismo error.

Cambio los componentes IBX por FIBPlus y da también errores de Deadlock (pero en menor medida), pero una vez que paro la aplicación y calculo cuantas veces se ha ejecutado la actualización en cada equipo veo que no coincide el valor final con el que debería ser.
Nota: cada vez que da error hago un rollback para deshacer la transacción.

Reviso los parámetros de las transacciones y creo que he puesto los correctos: consistency y wait que son los que me permiten lecturas repetibles y esperar frente a registros sucios. También lo pruebo con los parámetros por defecto que trae el componente de transacción.
Pues no entiendo porqué sucede esto. Y es un problema pues si las transacciones no funcionan bien, por ejemplo si varios procesos actualizan un saldo de forma simulatánea, no se garantiza que el valor final sea el correcto.
Primera pregunta: ¿esto es así o me estoy equivocando en algo? A la vista de las pruebas no sé que pensar.

Esto me lleva a plantearme la posibilidad de tener un tabla de semáforos para saber si puedo o no actualizar una tabla porque haya otro actualizándola. Pero claro, con la tabla de semáforos me encuentro en la misma situación al ser un recurso compartido. Es decir, necesitaría poder bloquear la tabla para acceso exclusivo. ¿Otro parámetro de la transacción "lock"?
Segunda pregunta: ¿como implemento un semáforo con tablas firebird?

Gracias.

[sur-se]

Hola. Replanteo el problema que he expuesto para ver si alguien le ha ocurrido lo mismo y saber como lo ha solucionado.
Supongamos que tenemos una tabla de artículos y uno de los campos es el stock actual de cada artículo. Desde varios equipo se realizan ventas de artículos, lo que repercute en acceder a dicho campo y disminuir el stock en la cantidad vendida. Por otra parte otros ordenadores están introduciendo compras, lo que repercute en el aumento de ese campo stock para cada artículo en concreto. Básicamente esto es lo que he simulado con la prueba descrita en el post anterior. Un registro que es actualizado simultáneamente desde varios equipos. El resultado final de las actualizaciones debe dejar un valor correcto de stock. Las premisas son las mismas:
- Las transacciones deben durar poco tiempo (el tiempo del update).
- Los recursos se toman y liberarn en el mismo orden (primero se actualiza una tabla y después la otra).
- Una transacción debería esperar (hacer wait) hasta que puediese actualizar el campo correspondiente, cuando otra transacción concurrente lo liberarse.

En el caso de tener configurado la transacción como No Wait, se captura la excepción y se genera un rollback que debería deshacer todo lo hecho.

Pues bien, la prueba que he hecho es básicamente lo descrito, pero si al final se mira el valor del campo que se incrementa y decrementa, el resultado no es el correcto, aun restando (por supuesto) las veces que dió error de deadlock (que por otra parte no debería dar pues puse la opción wait en la transacción ).

Alguien habrá resuelto esta cuestión de alguna manera ¿no?.
Gracias.

[valentine]

Hola,


Yo he tenido un problema parecido, cuando ejecutaba una modificación de vez en cuando tambien me daba un deadlock, era debido al objeto que estaba utilizando, que objeto están usando??

[sur-se]

El deadlock que se obtiene es de la base de datos. Los componentes que he usuado han sido IBX y FIBPlus (para dos pruebas separadas).

[brandolin]

He desarrollado varios sistemas en diferentes tipos de archivos de base de datos y el problema existencial que tuve es el de las actualizaciones de stock hechas desde las estaciones.

Ahora uso Firebird 1.5 y el problema lo he resuelto utilizando un trigger, asi el la cuenta del stock lo hace el mismo motor de base de datos y el cliente se olvida del problema.

Espero que te sirva la idea.

Gracias.

[sur-se]

Hola. Pero según creo entender, ¿tu reacalculas en cada momento el stock del artículo antes de mostrárselo al usuario? No te he entendido bien.

[sur-se]

Hola, he instalado Firebird 1.5.1 he puesto los componentes FIBPlus y configurado las transacciones como isc_tpb_read_committed y isc_tpb_wait. El problema ha desaparecido ya y las actualizaciones las hace correctamente, ejecutando los bloqueos bien. Parece que el F 1.5.1 va estupendamente.
Saludos.

[guillotmarc]

Hola.

No te puedo ayudar mucho con la configuración de transacciones con IBX y FIBPlus, puesto que no los utilizo.

Aunque el tema de asegurar el bloqueo de una tabla o un registro, lo puedes conseguir con un bloqueo pesimista. Consulta la página 13 de las Release Notes de Firebird 1.5.

Finalmente, el tema del cálculo de Stocks yo también lo realizo en Triggers (como ha comentado brandolin), y no se recalcula cada vez que consultas el Stock, sinó solamente cada vez que se dispara el trigger.

Saludos.

[celades]

Hola

Yo el tema de estocs lo resuelvo con una tabla temporal
Imaginemos que voy entrando lineas de albaran, al grabar la linea en Delphi lo que hago es grabar la linea en el temporal con otra transaccion y hago commit en la misma.
Con lo que si alguien consulta el estoc del articulo de la linea le muesto que quedan lo del estoc del articulo- todas las ventas del temporal +todas las compras del temporal con lo cual el estoc que muestro ( no el que tiene el registro del articulo ) siempre lo tengo actualizado al instante.
Si al final cancelo la entrada del albaran, simplemente borro las lineas del temporal con su transaccion y commit de la misma i rollback de la transaccion del albaran
Si al final valido el albaran hago commit de la transaccion del albaran
y anulo las lineas del temporal previo descuento del stoc del registro del articulo de la linea del temporal borrada i commit de su transaccion.

Espero haberme explicado pero yo es la manera que encontre de evitar deadlock sin hacer commit de la transaccion del albaran y a la vez evitar poder vender una unidat de estoc dos vendedores a la vez. Todo lo hago lanzando procedimientos adecuados pero la clave son las dos transacciones una en la que puedo hacer rollback y la otra con commits cada vez.

En fin cada uno se lo monta como puede, supongo que habra sistemas mas limpios, que este que es sui-generis mio.

Saludos