Select y Transacciones

[reevil]

Las transacciones son metodo para garantizar la integridad de nuestos datos en caso de ocurrir alguna problema al momento de realizar alguna transformacion de los datos, cuando haces un select no puede decirse que transformas datos pues solamente se crea una vista de las tuplas pero estas quedan intactas, entonces no es necesaria la transaccion.

Si me equivoco por favor de correjirme lo antes posible por que tengo mucho que correjir entonces

[[sitrico]]

Empezado por Mick

en ese caso tendrias que cerrarla y abrirla

Supongo que te refieres a la transacción (entiendo iniciarla y terminarla) porque los datos 99% de las veces abro, leo y cierro en un procedimiento (uso tablas temporales en memoria para trabajar tJvMemoryData)

Empezado por reevil

Si me equivoco por favor de correjirme lo antes posible por que tengo mucho que correjir entonces

Yo también por eso la pregunta...

[Mick]

Empezado por sitrico

Supongo que te refieres a la transacción (entiendo iniciarla y terminarla) porque los datos 99% de las veces abro, leo y cierro en un procedimiento (uso tablas temporales en memoria para trabajar tJvMemoryData)

Si no mantienes transacciones abiertas, salvo en casos muy especiales o que se lean miles de registros que tarden muchos segundos o minutos en recibirse, poco afectara el tipo de transaccion para la lectura.

Ya que la lectura de datos se hace en unos pocos milisegundos de modo que los datos leidos seran los mismos en el 99% de los casos, sea una transaccion tipo snapshot o read commited.

Saludos

[[sitrico]]

Bueno Mick, Me queda poco claro lo que comentas de las transacciones, (hablemos de las transacciones de solo lectura) esto fue lo que te entendí:

READ COMMITED ( RECORD VERSION )

las que yo uso.

Si hago varias consultas, en diferentes momentos, dentro de una misma transacción, se mostrarán los datos confirmados (con commit) actualizados

READ COMMITED (NO RECORD VERSION)

Igual pero si hay modificaciones en curso espera por el commit de esas transacciones. (posibles errores de concurrencia, más cuidado al usarlas)

SNAPSHOT

Tengo que terminar la transacción e iniciar una nueva para poder ver las actualizaciones de los datos. Esta requiere iniciar y cerrar las transacciones de lectura, no basta cerrar y abrir el dataset.

[Mick]

Me he liado un poco al explicarlo por falta de tiempo al redactar las respuestas, pero lo has entendido y resumido perfectamente XD.

Saludos

[Mick]

Empezado por reevil

Las transacciones son metodo para garantizar la integridad de nuestos datos en caso de ocurrir alguna problema al momento de realizar alguna transformacion de los datos, cuando haces un select no puede decirse que transformas datos pues solamente se crea una vista de las tuplas pero estas quedan intactas, entonces no es necesaria la transaccion.

Si me equivoco por favor de correjirme lo antes posible por que tengo mucho que correjir entonces

En interbase/firebird siempre se necesitan abrir una transaccion para lo que sea, si no hay transaccion no puedes leer datos. Las transacciones tambien afectan a la lectura de informacion, pudiendose leer registros distintos segun el tipo de transaccion que se utilice. Esto es debido a que el sistema de arquitectura multi-generacional de interbase es unico y la forma de guardar los registros y gestionar las transacciones es completamente diferente a cualquier otro sistema de base de datos. Por ejemplo en un cierto momento puede haber muchas versiones diferentes de un mismo registro guardadas en la base de datos.

Tipos de transacciones:

READ COMMITED ( RECORD VERSION )

Solo se ven los datos confirmados por otras transacciones, los datos que esten modificados por otras transacciones en curso no existen y se devuelve la ultima version confirmada de los datos.

READ COMMITED (NO RECORD VERSION)

Como la anterior solo se ven los datos confirmados por otras transacciones, pero si datos que es necesario leer han sido modificado por otras transaccions todavia no confirmadas, antes de leer estos datos, se espera a que esas otras transacciones se confirmen o cancelen, para tener asi los datos mas recientes posibles. Esto puede dar lugar a un interbloqueo y que la lectura falle por timeout en el caso de que otra transaccion que ha modificado datos que queremos leer, no finalice o tarde muchisimo en confirmarse o cancelarse. El tipo de transaccion anterior (RECORD VERSION) nunca tiene este problema ya que siempre devolvera los ultimos datos seguros aunque no necesariamente los mas recientes.

SNAPSHOT

Si leemos los datos con un transaccion tipo snapshot, no veremos ningun dato modificado posteriormente a la apertura de nuestra transaccion de lectura. Esto es como sacar una foto fija de la base de datos, tal cual estaba justo en el momento que se inicio la transacion, esto es util para generar informes y que estos sean coherentes, y no les afecten modificaciones de datos que se esten produciendo en el medio del calculo de los informes.

Como se puede ver segun el tipo de transaccion asociada a la lectura de informacion, los datos leidos pueden ser completamente diferentes.

Saludos

[reevil]

yo practiicamente solo manejo mysql , pero me parecio muy interesante y util la forma en que firebird maneja las transacciones, muchas gracias por el dato