FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Cuantas transacciones
Hola, como he dicho en otros posts de Delphi, soy nueva en esto de Delphi + Firebird 1.5.1, utilizando componentes IBX.
Tengo una aplicación, con las a/b/m usando IBDataSets para tablas no maestro, ClientDataSEts, para actualizar maestro-detalles, y IBQuery para realizar búsquedas. El asunto es que por ahora uso una misma txn para todo. Dependiendo que parte de la bd se está actualizando, es quien es usa la txn para sus procesos correspondientes. No he tenido inconvenientes, pero la intuición femenina me dice que no es lo mas aconsejable ....además leí en el Help de IBX que viene con Delphi que c/query debe tener su propia tnx, aun no he encontrado explicaciones para ello. Y como no conozco el funcionamiento interno de las txns, estoy en ascuas Se que la pregunta es un tanto general, pero ¿cual es el criterio para decidir entre una o mas tnx?. Les agradezco las sugerencias o comentarios a esto. Saludos, rochi |
#2
|
|||
|
|||
Cada transaccion define un conjunto de modificaciones sobre la base de datos que deben hacerse de forma atomica, eso significa que o se hacen todas o no se hace ninguna.
Esto permite mantener la coherencia en la base de datos aunque se produzca algun error en el medio de las transacciones, o algun conflicto con otro cliente/usuario. Asi que la cuestion no es ni tener una unica transaccion para todo ni una transaccion por cada query, sino que cada proceso hay que estudiarlo y definir una o mas transacciones segun sea necesario: Por ejemplo si tenemos un proceso de salida de articulos en el que realizamos lo siguiente: 1. Creamos un albaran de salida de articulos, guardando en una tabla de detalles la lista de articulos y cantidades que salen del almacen. 2. Actualizamos la tabla de stocks o de articulos restando las cantidades de cada articulo que han salido. En este proceso de ejemplo vemos que si por algun problema, se realiza el punto 1 del proceso, pero el punto 2 da error (supongamos que se perdio la conexion de red entre medias) la base de datos quedara con informacion incoherente, tendremos un albaran que nos indica que ha salido determinado material pero si miramos el stock, en este nos constara que tenemos articulos de mas (porque no se ha podido restar las cantidades por el error anterior). Luego para este proceso: -Iniciamos una transaccion (Start) -Realizamos el punto 1 -Realizamos el punto 2 -Si todo ha ido bien, confirmamos la transaccion (Commit). -Si se produce algun error en alguno de los puntos: cancelamos (RollBack) Al realizarse los dos procesos dentro de una misma transaccion si el punto 2 da error y no puede realizarse, hariamos un rollback de modo que la transaccion se anularia, lo que implica que todos los procesos realizados anteriormente desde que se inicio la transaccion son cancelados, es como si nunca se hubiese realizado el punto 1, de modo que nunca tendremos incoherencias entre informacion relacionada que se encuentre guardada en distintas tablas de la base de datos. En este ejemplo vemos que tendriamos una unica transaccion para el proceso, pero ejecutariamos varias queries de actualizacion sobre la base de datos, todas estas queries tienen que utilizar esa misma transaccion. Lo que si se puede hacer para ahorrar en el uso de componentes TIbTransaction es utilizar un unico componente TIbTransaction con un nivel de aislamiento: ReadCommited, para todos los procesos y queries de consulta del programa. Es decir operaciones que no impliquen modificaciones en la base de datos: listados, consultas , etc, todas podrian utilizar el mismo componente. Saludos |
#3
|
|||
|
|||
Muy claro los 2 ejemplos. Similares en el concepto.
Me quedó claro que las txns las debo usar con el criterio de mantener la coherencia de los datos en un proceso. El corolario primario de todo esto, es que la cantidad de txns dependerá de cuantas cosas (queries,ibdataset,etc) estén involucradas y deba agrupar para realizar un proceso con éxito. Pero he aqui mi nueva duda: Cita:
Tal vez no te entendí...y por eso mis preguntas,..te agradezco la aclaración Muchas gracias, la verdad muy claros sus ejemplos Saludos rochi Última edición por rochi fecha: 22-12-2004 a las 21:26:39. |
#4
|
|||
|
|||
Todas las querys, procedimientos almacenados y triggers que se disparen están bajo la transacción que esté asociada al componente, es decir, los triggers van asociados a la transacción del componente que provocó su disparo.
Por otra parte, quiero hacer una pequeña aportación a todo esto de las transacciones. Normalmente, para las aplicaciones SDI el número de transacciones a utilizar será menor que en aplicaciones MDI (en las que podríamos tener varias ventanas y procesos simultáneos), simplemente por el hecho de que sólo podemos tener una ventana activa en cada momento (ignorando a groso modo los posibles threads). De todas formas, es evidente que las transacciones van a depender de los procesos que realices y de como programes. Lo que si hay que tener claro es que si una transacción modifica datos, que termine lo antes posible (es decir que no requiera la interacción del usuario). Salu2. |
#5
|
|||
|
|||
Cita:
Pero hace que entienda menos la frase de StartKill, no digo por el, por mis limitaciones... "ahora otro dira pero mejor usa un procedure para tu actualizacion con su respectiva transacion" que se refiere a la actualización de 2 tablas que por algun motivo están relacionadas. Asumo que hay 2 txns diferentes...por eso preguntaba........y que aun no entiendo Saludos, rochi |
#6
|
||||
|
||||
Wnas foro,
j,j,j,j,j, tienes razon son parecidos las dos repuesta pero te aseguro que nadie copio del otro (lo digo por mi), hoy reviso el foro y me di cuenta que my friend Mick me gano en la respuesta (digita ud. mas rapido que yo). Hola Rochi, te preguntas por el comentario que hice: original de StartKill Cita:
Original de rochi Cita:
Ahora, esta demas decir que si tienes un procedure que maneje "n" tablas... solamente necesitaras una transaccion--->para el stored procedure y ningun ibquery-innecesario,.... claro que la transaccion que apunta a dicho stored procedure podra hacerlo a otros componentes "Ibquerys, storedProcedure..."(como tu dices: para mantener la coherencia de datos). Bueno, me despido y gracias a nuestros Moderadores, Amigos... que hacen posible compartir nuestras experiencias y que podamos consultar dudas que nos caen dia a dia. Un Abrazo y una Feliz Navidad y Prospero año Nuevo 2005. Your friend, StartKill Lima-Perú. Es bueno probar y experimentar para tener experiencia, pero es mas agradable que me enseñen para evitar perder tiempo y equivocarme tontamente. Última edición por StartKill fecha: 23-12-2004 a las 22:53:40. Razón: puntualizar.. |
#7
|
||||
|
||||
Wnas foro
Esta pregunta me la plantee hace un buen tiempo: "que es recommendable?", una transaccion por ibquery o una transaaccion por todas... ibquery, ibsql... La poca expereciencia en el mundo de la programacion de delphi con interbase y debo suponer con otros lenguajes y motores de base de datos cliente servidor me ha enseñado:Que el uso de las transacciones es a buen criterio del programador (segun la necesidad), te doy un ejemplo y saca una conclusion de ello. Debo suponer que conoces ya el uso de los componentes ibx y al menos algunos conceptos en la programacion de ellos... Supongamos que tenemos dos tablas: una es la Clientes y la otra la de Abonos, lo justo y normal es que exista un registro en Clientes y cero, uno o varios registros en la tabla abonos por cada cliente. Código PHP:
Imaginemos la actualizacion de estas tablas.... Código PHP:
Si hubiera sido dos transsaciones una para cada tabla???? Imaginate que la primera transsacion se confirme osea la de clientes y por alguna razon del destino en la segunda tabla de abonos ocurre algun error: (error de unique, clave foranea...cualquier error)...ah??, como quedan las tablas??... respuesta: solo la tabla clientes confirmada la transaccion y la segunda "rollback", transaccion deshecha. y tus tablas no quedarian consistentes (la suma de abono en la tabla abonos no reflejaria lo que indica en abono de la tabla clientes). Entoces en este caso se sugiere usar una sola transaccion... ahora otro dira pero mejor usa un procedure para tu actualizacion con su respectiva transacion----tienes razon, pero esto es un ejemplo que se me ocurrio para explicar el uso de las trasacciones Bueno, no soy profesor, espero haberme hecho entender: eso depende de tu necesidad, una de las ideas del uso de las transaciones es la consistencia extra de tus datos...(o todo o nada) Your friend, StartKill Lima-Perú |
|
|
|