¿Cómo usar mejor las transacciones?

[ferysil2003]

Hola compañeros de programación.

Estoy haciendo pruebas de programación en delphi 7, firebird y componentes fibplus de devrace.
Lo cierto es que lo llevo bastante bien, pero antes de empezar en serio con un proyecto que tengo en mente tengo que practicar mucho y estar seguro de lo que hago para evitar problemas en el futuro.
Según veo yo lo más importante es tener claro como usar las transacciones y despues de leer mucho siempre se dice que deben de ser lo más cortas posibles.
En mis pruebas uso un data module en donde tengo el componente TpFIBDatabase para conectar a la base de datos firebird y varios componentes TpFIBDataset, por ejemplo uno llamado DataSetClientesLista para acceder a una lista de clientes, dataset al que modifico la sentencia sql para filtrar el resultado. Ademas como dicho dataset tiene que tener una transaccion asociada el componente TpFIBTransaction lo tengo en el formulario donde tengo el dbgrid, y mi proceso es el siguiente. Cuando creo el formulario, modifico el selectsql del DataSetClientesLista, asocio la transaccion de ese formulario al DataSetClientesLista, abro la transacción y despues abro el DataSetClientesLista.
El resultado me lo muestra en el dbgrid, y cuando cierro el formulario cierro todo, la transaccion y el DataSetClientesLista.
El dbgrid solo es de consulta, nunca para modificar ni para borrar. Así pues el tiempo de duración de la transacción es el tiempo que tengo abierto el formulario de consulta. Supongo que estará bien hecho, a mi no se me ocurre otra cosa.
Mi dilema viene cuando uso un formulario para modificar un ficha.
El proceso que hago es parecido al anterior, al crear el formulario que contiene los campos de la ficha asocio a un DataSet llamado DataSetCliente la sentencia sql que me devuelve sólo ese registro, le asocio la transaccion que la tengo en el formulario llamado Ficha Clientes, abro la transaccion y abro el DataSetClientes, y lo pongo en modo edicion. En el formulario con la ficha del cliente a modificar uso componentes DBEdit. Al pulsar aceptar hago un commit de la transaccion y cierro del DataSetClientes. Esto me funciona pero mi dilema es si es mejor esta opción o para que la transaccion dure menos debería de crear un formulario con campos edit el cual al crearlo hacer una consulta de lectura sobre la base de datos que me devolviera el registro de ese cliente y copiar yo los datos sobre cada campo edit, de esa manera abriría la transaccion, leería el registro, copiaría los datos sobre mis campos y cerraría la transaccion. Despues de modificar los campos oportunos, abriría de nuevo la transacción, enviaría una sentencia update de los campos modificados, y cerraría la transaccion. A nivel de programación sería algo más laborioso, pero de esa manera las transacciones serían muy cortas.
Os pido vuestra opinión al respecto y gracias de antemano por el tiempo altruista que dedicais.

[PedroAlfonso]

Estimado Ferysil:
Yo uso Edits exactamente para lo que tu dices, hacer las transacciones cortas a la hora de modificar o insertar los datos. En mi opinión es lo más seguro y he leído en otros foros a programadores que opinan igual.
No te preocupes por la duración de las transacciones cuando solo lees datos, uno de los motivos más importantes por los cuales existen las transacciones es para modificar varias tablas segun tu proceso, y en caso de error poder deshacer toda la transacción (rollback) para cuidar la integridad de los datos.
Lo recomendable es guardar (modificar) los datos dentro de un Try-except para en caso de falla utilizar el rollback.
Espero haberte ayudado un poco.

[[Crandel]]

Hola ferysil, hay un detalle que me parece que te tiene confundido.

Empezado por ferysil2003

Según veo yo lo más importante es tener claro como usar las transacciones y despues de leer mucho siempre se dice que deben de ser lo más cortas posibles.

Es termino de corta no hace referencia a la duración en tiempo a la cual la transacción esta abierta, sino al tamaño del flujo de datos.

Por ejemplo, si cada vez que modificas tu tabla "Productos", la cual supongamos es muy grande, y grabas la modificación. Este proceso tiene que actualizar la tabla en tu programa, lo cual implica un flujo de datos grande.

Si estas viendo los productos y te paseas todo lo que quieras entre ellos durante un día completo, no hay trafico de datos, se realizo una sola vez cuando te ttrajiste la tabla y luego recorres sobre una copia local.

Espero que aclare.

[ferysil2003]

Gracias PedroAlfonso.
Gracias Grandel.

[1111111]

Yo hago lo mismo que PedroAlfonso.

- Abro transacción.
- Cargo datos en edits o combos.
- Cierro transacción.

Y lo mismo para guardar las modificaciones.

No me fio mucho de las transacciones de Interbase.

[[Crandel]]

Empezado por 1111111

No me fio mucho de las transacciones de Interbase.

por alguna razon en especial?

[Rufus]

Crandel, en sintonía con otros comentarios de este hilo, voy a tener que discrepar un poquito contigo. En la experiencia que pueda tener con firebird te puedo decir que en el rendimiento y seguridad de la base de datos afecta tanto el volumen de traspaso de datos y las características de cada transacción (lectura o escritura, wait o no_wait, nivel de aislamiento) como el tiempo que estén abiertas, sobre todo si son de escritura.

Esto es sencillo de ver: en un entorno multiusuario, si permitimos que las transacciones de escritura sean largas en el tiempo estamos permitiendo la posibilidad de que en un momento dado existan un elevado numero de transacciones de escritura abiertas al mismo tiempo, causando entonces:

• Problemas de concurrencia y consistencia de los datos
• Problemas de rendimiento. La base de datos tiene que soportar un aumento considerable de sus transaction inventory pages, entre otras cosas.
• Tambien aumenta la posibilidad de errores fisicos en la base de datos, esos que tras los cuales hay que ejecutar un gfix o un restore en el peor caso.

Claro que si se trata de una aplicación local para un único usuario los problemas se minimizan bastante.

[1111111]

Empezado por Crandel

por alguna razon en especial?

Antes que nada, aclaro que yo me referia a Interbase, no preste atención cuando decias que usas Firebird, perdón.

En cuanto a Interbase, en lo que no confio es en la perdida de memoria que genera Interbase, por perdida me refiero a que al momento de cerrar una transaccion se deberia liberar la memoria utilizada por la pc local y esto no ocurre. Con el consecuente aumento de la utilizacion de memoria por parte del programa que se esta ejecutando.
De todas formas este problema me parece que lo tienen los componentes IBX, y vos dijiste que usabas otros, asi que no se aplicaria a tu caso este problema.

[[Crandel]]

En prácticamente todos lo programas que he realizado mantengo mis transacciones abiertas (las de uso continuo), y nunca tuve ningún tipo de problemas de concurrencia, consistencia de los datos ni ningún otro.

Los programas si son muchos, aunque ninguno supera los 10 clientes simultaneos.

Pero si hay que tener en cuenta que en un par tengo el servidor corriendo en maquinas con pentium 100 y 120 MHz con 32 Mb de Ram, sin ningún tipo de problema.

[[Crandel]]

Me dejaron pensando en el tema

Supongamos que queremos editar un dato de una tabla y hacelos lo que no sugiere 11111111:

Empezado por 1111111

- Abro transacción.
- Cargo datos en edits o combos.
- Cierro transacción.

Luego modificamos los datos y supongamos que alguien en ese instante más rapido que nosotros los modifica.

Luego nostros al querer actualizar ese registro introduciriamos datos incorrectos poruqe estariamos sobreescribiendo algun valor que el otro usuario puede haber modificado.

Y justamente aqui es donde se produce el problema de consistencia de los datos.

Mi sugerencia es:
* si no confian en el mecanismo de control de concurrencia de su motor de base de datos -> cambien por otro.

Tomen en cuenta que tanto Interbase como Firebird permite definir algunas formas de controlarlo desde nuestra aplicación.

Saludos.

[ferysil2003]

Mi idea de tener abierta una transaccion poco tiempo abierta en tiempo lo digo pensando en lo siguiente: De todos es sabido que lo más difícil de controlar en un programa son los errores que puedan cometer los usuarios que luego usen nuestra aplicación y los cuelgues en los ordanadores. Pensando en esto es por lo que pienso que si un usuario abre una transaccion para modificar un registro, lo estás modificando, tarda cierto tiempo y su ordenador se cuelga (que ocurre), ¿qué pasa con todas esas transacciones que quedan abiertas y nunca se cierran?, pienso que esto puede llevar a problemas.
De todas formas Crandel el problema que planteas de la actualización de dos usuarios a la vez tiene una fácil solución. Se podría poner un campo e incrementarlo con un trigger siempre que se actualice ese registro. Al leer un registro para editarlo, leemos este campo y si cuando mandemos la orden de actualizacion si el valor de este campo no es el que leímos originalmente es porque alguien ha actualizado el registro.

[[Crandel]]

Hola, es verdad que mantener el menor tiempo posible las transacciones abiertas.

ferysil, hace mucho implemente (a medias) una solución como la que comentas cuandro trabajaba con tablas paradox y queria hacerlas multiusuario.

Hoy en dia, todo ese control ya lo realiza el mismo motor.

Aca les dejo un link donde esplica un poco el tema de las transacciones:
http://www.clubdevelopers.com/delphi...fastfb/fb6.php

Con esto no quiero decir que yo lo este haciendo perfectamente, ni lo creo, pero posiblemente con esta discución podamos encontrar una mejor solución para todos y aprendamos más.

Suerte y espero sus comentarios y experiencias.

[jzginez]

Hola amigos, tiene un buen que estoy desconectado del foro pero hoy que porfin pude entrar checando este hilo y esperando no haber perdido la practica en cuanto a delphi, firebird y fibplus (ya que por otro proyecto desde finales del año pasado no las uso).

Despues de leer la lija de Cardel

Aca les dejo un link donde esplica un poco el tema de las transacciones:
http://www.clubdevelopers.com/delph...tfastfb/fb6.php

y con lo poco que yo tengo entendido, el tiempo de vida de una transacción puede ser largo o corto pero este no tiene que ver con tiempo que el componente TpFIBTransaction este activo o no, sino con el tiempo que tardamos en realizar un Commit o Rollback despues del insert, append, edit, delete.

Ya que si no usas delphi y solo desde un administrador de BD's como IBExpert usas un insert y no das el commit te indica un error al querer ejecutar otra accion u otro insert indicandote que la transacción no se a cerrado.

Ahora bien el TpFIBDataset de las FibPlus tiene una propidad autocommit la cual tienes que pones en verdadero para que se cierren las transacciones de forma automatica y no tengas que estar programando el CommitRetaining, al igual que Cardel tengo sistemas donde nunca cierro el componente TpFIBTransaction y hasta el momento no he tenido problemas, los tuve cuando no cambiaba la propiedad de autocommit a verdadero.

[Rufus]

Aqui les dejo este manual sobre transacciones en interbase y firebird
http://www.terra.es/personal2/jrodri...ones-0.2.6.pdf

Un saludo