¿Para qué RollbackRetaining?

[[Al González]]

¡Buen día a todos!

He leído algunos documentos que hablan de usar los métodos de TIBTransaction, CommitRetaining en los eventos AfterPost y AfterDelete de los conjuntos de datos, y RollbackRetaining en el evento AfterCancel.

Comprendo la utilidad de los dos primeros, pero no se exactamente con qué fin se utiliza RollbackRetaining en AfterCancel, cuando por lógica (aparentemente) no hay nada que deshacer transaccionalmente hablando. Ya que, hasta ese punto, los datos que se hayan introducido en una inserción o modificación de registro están sólo en la memoria del conjunto de datos en la aplicación, y al cancelar, pues simplemente desaparecen de la memoria del programa sin que se haya afectado a la base de datos.

Les agradezco que me orienten con la anterior duda.

Agrego, que en uno de mis proyectos IBX-Firebird, estoy utilizando las propiedades DefaultAction = TACommitRetaining e IdleTimer = 250 del objeto TIBTransaction principal. Dejar de usar estas propiedades no sería mucho problema, ya que desarrollé componentes derivados de los IBX, en los cuales podría implementar internamente las llamadas a CommitRetaining y RollbackRetaining necesarias. Pero... ¿para qué RollbackRetaining?

Un abrazo, chao.

Al González .

[Gydba]

No es concretamente lo que buscás pero te paso una porción de un post de Jason Wharton en otro foro:

Rollback retaining is quite a bit more difficult to implement than
CommitRetaining. It is especially more difficult to respond to on the client
if record buffering is going on.

By doing a CommitRetaining you are ensuring that which is in the client
buffers matches what is the committed state on the server. Thus, as a result
of it the client and server are in sync with eachother. This is easy to deal
with.

When a RollbackRetaining is performed this causes the server to disregard
all the data manipulation requests that the client has made. This causes the
current state of the buffers to become out of sync with the server. Not os
easy to deal with.

What needs to happen to make this work is one of two things. Either the
client refreshes all of its datasets (in which changes were made since being
opened) after the RollbackRetaining is performed so that they are back in
sync or the client needs to keep track of every change that has been made
and then effectively reverse those changes item by item in the buffers. Or,
it could selecitively refresh just those rows affected. As long as triggers
have done furthur changes the client and server would be back in sync.

Otro enlace de interés:
http://delphi.weblogs.com/stories/storyReader$379

Personalmente, y por consejo de MUCHA gente, he decidido no utilizar la retención de las transacciones para dar paso directamente al commit y al roolback.

[Mick]

El problema es que los datos modificados si se envian y afectan a la base de datos.
Si una transaccion modifica un registro, y otra transaccion modifica ese mismo registro antes de que la primera transaccion finalize o se cancele, pueden pasar dos cosas segun como este configuradas las transacciones:
1. La segunda transaccion tiene que esperar a que la primera haga un commit o un rollback.
2. O la segunda transaccion da directamente un error de conflicto de bloqueo.

Si la segunda transaccion pudiese modificar a su antojo cualquier registro modificado por alguna transaccion previa no finalizada, el mecanismo de transacciones no serviria para nada ya que no aseguraria la serializacion de las operaciones ni la congruencia de los datos.

Un Saludo
Miguel