FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
¿Para qué RollbackRetaining?
¡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 . |
#2
|
|||
|
|||
No es concretamente lo que buscás pero te paso una porción de un post de Jason Wharton en otro foro:
Cita:
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.
__________________
Suerte .: Gydba :. |
#3
|
|||
|
|||
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 |
|
|
|