Problema en el uso de Transacciones

[jachguate]

Te sugiero evaluar el uso de actualizaciones en cache (cachedupdates). Esto hará que los cambios aplicados por el usuario a los datasets sean almacenados en memoria hasta que llames a applyUpdates, logrando que la duración de la transacción sea mínima, sin perder la capacidad de dar marcha atras si el usuario se arrepiente (CancelUpdates)

Hasta luego.

[AGAG4]

Entonces la Transacción empieza cuando aplico un applyUpdates????

Agradezco sus comentarios....

[vtdeleon]

Saludos.

Empezado por AGAG4

Entonces la Transacción empieza cuando aplico un applyUpdates????

Agradezco sus comentarios....

Debes tener (En el dataset que uses) la propiedad CacheUpdate en True, Si quieres guardar los datos en memoria en la tabla usas AppyUpdate, sino CancelUpdate. La ayuda de delphi puede guiarte un poco

[jachguate]

Empezado por AGAG4

Entonces la Transacción empieza cuando aplico un applyUpdates????

Agradezco sus comentarios....

La transacción inicia cuando haces un select, pero es una transacción de solo lectura que no afecta a nadie. Esta transacción será promovida a una de lectura/escritura cuando llamas a apply updates.. que aún con cientos de actualizaciones tardará solo unos instantes, ya que inmediatamente después haras commit, y asunto olvidado.

Entonces la contención y la posibilidad de deadlocks es reducida en gran cantidad.. .aún cuando sigue siendo posible que dos clientes colisionen... es mucho menor en entornos con pocos usuarios. Y entonces podes dejar las transacciones en modo wait, puesto que la espera será realmente corta.

Hasta luego.

[AGAG4]

Muchísimas gracias por sus comentarios son muy valiosos, hare lo que me recomiendan....

Que tengan Muy Buen Día....

Saludos....

[AGAG4]

Con respecto al Guardado en la Cache del ibDataset, el problema que tengo ahora, es que en la llave primaria del Detalle es Serie+Folio+Indice, donde indice es un consecutivo, donde cada vez de que se inserte un nuevo registro va tomando el Siguiente, esto lo hacia por medio de un Procedimiento Almacenado, pero ahora que no se va a la BD si no a la Cache quize hacer la prueba del cual muestro a continuación:

Código Delphi [-]
....
var
Marca:TBookMark;
eve:TDataSetNotifyEvent;
begin
with dmFactBabatsa do begin
BookMarkDFAC:=true;
if tDFacturas.RecordCount<1 then
result:=1
else begin
try
eve:=tDFacturas.BeforePost;
tDFacturas.BeforePost:=Nil;
Marca:=tDFacturas.GetBookMark;
tDFacturas.DisableControls;
{Empieza la Acción....}
{AQUI MARCA ERROR, ES DECIR LLAMA AL EVENTO BEFORE POST}
{E INTENTA HACER EL POST Y MARCA ERROR EN CAMPO INDICE QUE LLAVE}
{PRIMARIA ESTA INCOMPLETA, AUN ASI ENTRA AL EVENTO AUNQUE }
{ANTERIORMENTE LE HAYA PASADO EL VALOR NIL}
tDFacturas.First;
 
while not tDFacturas.Eof do begin
result:=tDFacturasINDICE.value+1;
tDFacturas.Next;
end;
{Finaliza la Acción....}
tDFacturas.GotoBookMark(Marca);
{Tomar Posición Original}
tDFacturas.EnableControls;
tDFacturas.BeforePost:=Eve;
finally
tDFacturas.FreeBookmark(Marca);
end;
end;
BookMarkDFAC:=false;
end;

Sugerencias para Tomar Totales de Factura ó Tomar el Indice Consecutivo dentro de la Cache????

Agredezco cualquier sugerencia.

[AGAG4]

Otra Cosa Juan Antonio porque menciona esto....

"es mucho menor en entornos con pocos usuarios."

El método de uso de Cache no funciona como debiera con muchos Usuarios accesando al mismo tiempo en una Base de Datos????

Es la otra duda que me quedo respecto a sus comentarios....

Que Tenga Buen Día....

[AGAG4]

No tuve más remedio que lidiarme con un DBF Físico, le añadí los campos que ocupo para determinar el INDICE de la llave primaria y para los TOTALES de la Factura y me funcionó, no encontre nada como crear una tabla en memoría y lidear con ella....

Saludos.

[jachguate]

Hola.

Empezado por AGAG4

Otra Cosa Juan Antonio porque menciona esto....

"es mucho menor en entornos con pocos usuarios."

El método de uso de Cache no funciona como debiera con muchos Usuarios accesando al mismo tiempo en una Base de Datos????

Lo que yo dije fué:

Empezado por yo mero

Entonces la contención y la posibilidad de deadlocks es reducida en gran cantidad.. .aún cuando sigue siendo posible que dos clientes colisionen... es mucho menor en entornos con pocos usuarios. Y entonces podes dejar las transacciones en modo wait, puesto que la espera será realmente corta.

Me refiero a que la probabilidad de que ocurran deadlocks o problemas de concurrencia (contención) es tan baja en entornos con pocos usuarios, que al usar este método podes olvidarte de ella. En cambio, en entornos con muchos usuarios esta probabilidad va subiendo de manera que tendrias que programar algo para lidiar con ella.

Imagina un entorno donde las transacciones que tardan 0.1 segundos, gracias al uso de actualizaciones en cache. Nos pondremos en el escenario de un supermercado con 200 cajeros y que en un momento particular todos venden cocacola y panecillos (que están en oferta). Aún cuando las transacciones son realmente cortas, la probabilidad de que dos cajeros finalicen una factura al mismo tiempo, y que esta tenga que afectar la existencia de un mismo artículo es ya importante... quizas una vez a la semana, talvez hasta una vez por hora. Entonces habrá que hacer algo para interceptar el error y lidiar con él.. p. ej. hacer esperar a uno de los dos cajeros medio segundo y reintentar la operación.

Hasta luego.



pd. Es buena idea que edites el mensaje que obliga a que sea necesario correrse a la derecha para poder escribir esto.... es realmente molesto.