Desesperación Bloqueos

[Rockin]

Hola, estoy usando CDS, este está asociado a su DataSetProvider, este a su TTransaction y este a su DataSet.

En el evento AfterApplyUpdate del DataSetProvider, tengo lo siguiente:

Código Delphi [-]
if TContacto_leads.InTransaction then
begin
        TContacto_leads.Commit;
end;

¿Donde debo abrir la nueva transaccion? ¿en el CDS? ¿en el servidor de capa intermedia? Estoy algo perdido.


Saludos

[[Lepe]]

La solución es gratuita, pero lleva tiempo. La tienes en los documentos de Interbase/Firebird (data definition guide, etc) en http://www.ibphoenix.com/resources/documents/general

Lo siento pero no hay magia, tus necesidades pueden ser diferentes a las mías, por eso no puedo aconsejarte. Si te fijas casi nadie pregunta ese tipo de cosas porque lee la documentación, se empapan de todo lo que necesitan entender, configurar, etc y en este foro solo se viene a preguntar por "ideas de procedimientos almacenados", trucos de SQL, de programación y tal.

[Casimiro Noteví]

Paisano, Rockin, aunque estés desesperado, pero recuerda poner un título descriptivo a tu pregunta. Gracias, amigo

[guillotmarc]

Empezado por Rockin

Hola, estoy usando CDS, este está asociado a su DataSetProvider, este a su TTransaction y este a su DataSet.

En el evento AfterApplyUpdate del DataSetProvider, tengo lo siguiente:

Código Delphi [-]if TContacto_leads.InTransaction then begin TContacto_leads.Commit; end;


¿Donde debo abrir la nueva transaccion? ¿en el CDS? ¿en el servidor de capa intermedia? Estoy algo perdido.


Saludos

No es necesario ningún código de este tipo, puesto que el Provider del ClientDataset ya abre y cierra una transacción por si mismo.

Así que simplemente deja la transacción cerrada.

Naturalmente tienes más código. Primero porqué desde un CDS no puedes lanzar SP como el que comentas en el primer post, y segundo, porqué si te saltan bloqueos, es que estás manteniendo transacciones abiertas.

Si tienes todas las transacciones cerradas, no te puede saltar ningún error de bloqueo por abrir momentaneamente una transacción para realizar un cambio sobre un registro.

Recuerda, si te salta un bloqueo es porqué intentas modificar un registro desde una transacción que ha estado abierta desde antes que otra transacción haya modificado el mismo registro.

Revisa tu código, y cierra las transacciones que estás dejando abiertas. Cuanto menos tiempo queden abiertas, menos problemas tendrás.

[Rockin]

Perdon Casimiro Notevi.

Seguire probando y leyendo a ver si me aclaro, pero no lo veo, creo que está todo correcto. Algo se me está escapando.

Si guillotmarc , tengo más codigo el procedimiento lo llamo así:

Código Delphi [-]
       with datDatosRemoto.CDSLeads do
        begin
                Close;
                CommandText:= 'select telefono from SP_PEDIR_CONTACTO_LEADS';
                Open;
                Execute;
            
        end;
:

El codigo que tengo puesto en el Provider lo vi en el libro la cara oculta de delphi 6. En el resto de transacciones ma va biem pero aqui al ser transacciones muy seguidas puede que me falle por eso. No se que hacer............

[Casimiro Noteví]

Es que, como dice guillotmarc, un deadlock sólo se produce cuando hay otra transacción abierta sobre el mismo registro, grabando. No importa las de lectura.
Así que sólo queda el que las revises, porque seguro que algo se te ha escapado por ahí.

[guillotmarc]

Hola Casimiro.

Empezado por Casimiro Notevi

Es que, como dice guillotmarc, un deadlock sólo se produce cuando hay otra transacción abierta sobre el mismo registro, grabando. No importa las de lectura.
Así que sólo queda el que las revises, porque seguro que algo se te ha escapado por ahí.

Otra posibilidad de deadlock es cuando tu misma transacción actual lleva demasiado tiempo abierta (incluso sin haber hecho aún la menor escritura).

Si una segunda transacción ha modificado entretanto un registro, aunque esa segunda transacción de modificación ya haya finalizado hace tiempo, tu no podrás volver a modificar el mismo registro dentro de la transacción actual. Puesto que tienes un conflicto entre la versión del registro que tienes en la transacción actual, y el registro real en la base de datos (que actualizó la segunda transacción, ya cerrada y finalizada).

No sé si me he sabido explicar .

Por eso no me gustan los componentes como FibPlus, IBX, etc. ..., porqué prácticamente te obligan a mantener abiertas transacciones, y eso es una fuente segura de problemas.

Afortunadamente enlazarlos con ClientDatasets te solventa todos estos problemas, puesto que ya no necesitas dejar transacciones abiertas ni siquiera para lectura (que son las transacciones que se convertirán en problemáticas al querer pasarlas a transacciones de escritura cuando el usuario ha finalizado de trabajar con esos datos).

Las transacciones nunca se diseñaron para que estuvieran abiertas mientras el usuario trabaja con la información relacionada. Se supone que sirven solo para agrupar un conjunto de escrituras, y poder asegurar de que se hacen de forma conjunta (de forma que los datos sean coherentes a unas reglas de negocio).

Saludos.

[Casimiro Noteví]

Sí, se entiende.

[guillotmarc]

Hola.

Empezado por Rockin

... .... ... . En el resto de transacciones ma va biem pero aqui al ser transacciones muy seguidas puede que me falle por eso. No se que hacer............

Creo que ya te lo he insistido antes : No dejes transacciones abiertas y la posibilidad de bloqueos se vuelve prácticamente nula (solo pueden ocurrir cuando realmente se intente modificar el mismo registro en los mismos milisegundos).

Se te están quedando abiertas transacciones, y hasta que no lo corrijas seguirás teniendo problemas de bloqueos.

Puedes empezar verificando el estado de todas tus transacciones antes de lanzar esa modificación de registros (añade unas pocas líneas de código que te avisen si alguna de las transacciones está abierta en ese momento). Si es necesario también puedes utilizar las tablas de monitorización de Firebird para ver las transacciones que llevan más tiempo abiertas.

Ejemplo : http://www.firebirdfaq.org/faq352/

Mantener abiertas transacciones de lectura no es ningún problema, pero todas las escrituras deberían ejecutarse en el menor tiempo posible : abrir transacción, modificar registros y finalizar transacción inmediatamente. Es la única forma de evitar bloqueos, y es que es lógico que haya bloqueos cuando las transacciones se alargan, ¿ que se supone que debería hacer el motor de base de datos en estas situaciones ?, para respetar la integridad de los datos implicados en la transacción no tiene otro remedio que activar un deadlock (conflicto).

Saludos.

[Rockin]

Hola , ante todo gracias por ayudarme y perdonadem si estoy dando mucho el coñazo.

Empezado por guillotmarc

Creo que ya te lo he insistido antes : No dejes transacciones abiertas y la posibilidad de bloqueos se vuelve prácticamente nula (solo pueden ocurrir cuando realmente se intente modificar el mismo registro en los mismos milisegundos).

Saludos.

No te enfades conmigo, guillotmarc, es que no se donde se queda la transaccion abierta o por que, es decir en el evento Execute del CDS tengo puesto CDS.ApplyUpDates(-1) y en el DataSset, he puesto la propiedad Autocommit a true. Teoricamente al realizar el commit, se cierra la transacción ¿no? ¿O me estoy equivocando en este concepto?. LLevo cuatro años con estos componentes y nunca me ha pasado este problema y ando muy perdido. Es una aplicacion Cliente-Servidor con 3 servidores de capa intermedia balanceados por carga.

[guillotmarc]

Hola.

Empezado por guillotmarc

Puedes empezar verificando el estado de todas tus transacciones antes de lanzar esa modificación de registros (añade unas pocas líneas de código que te avisen si alguna de las transacciones está abierta en ese momento). Si es necesario también puedes utilizar las tablas de monitorización de Firebird para ver las transacciones que llevan más tiempo abiertas.

Ejemplo : http://www.firebirdfaq.org/faq352/

¿ En que parte te pierdes ?.

[Rockin]

No se donde estoy fallando, teoricamente todas las transacciones se deben cerrar rapidamente. Le voy a poner un timeout al componente transaction a ver si así soluciono el tema. Lo he revisado todo mil veces.

Gracias y ya os contaré.

Saludos.

[guillotmarc]

Sí, yo siempre configuro mis transacciones con un timeout de 1 milisegundo (lo puedes hacer con toda seguridad, incluso aunque tus sentencias tarden más de 1 milisegundo en ejecutarse, puesto que este timeout solo se activa cuando la aplicación está en espera).

¿ Has verificado las transacciones más largas en curso ? (tal y como indica el artículo enlazado). Puede ser que el conflicto lo provoquen transacciones que ni siquiera sean de tu aplicación, sino conexiones de terceros a la misma base de datos.

¿ Has probado a añadir unas pocas líneas de código al actualizar, que te avisen de si algunas otras de tus transacciones están abiertas ?.

Saludos.