Select y Transacciones

[sitrico]

Desde hace algun tiempo tengo esta duda:

¿ Se requieren transacciones para las consultas con "Select" ?

Porque cuando trabajo, generalmente defino en el data module sólo 2 transacciones una Read Commited y otra Read_Write Table Stability, entonces asigno la "Read Commited" para todas las querys (MDOQuery) con select (sin usar StartTransacction ni commit) y la segunda para todas las actualizaciones (Insert, Update y Delete), iniciando la transacción justo antes del execSQL y ejecutando el commit inmediatamente despues.

Lo que sí hago es usar algo así (en los Select):


Query.Open;
// leer Datos
// While eof
// lo que sea
Query.Close;
//Siempre cierro la consulta al terminar.



y en las actualizaciones:


// Preparar SQL
///INSERT INTO...
// UPDATE ...
// DELETE FROM....
Try
Transaction.StartTransacction;
ExecSQL;
Transaction.Commit;
Except
on E: Exception do
Begin
Transaction.RollBack;
ModalResult := mrNone; // generalmente al pulsar Ok
StatusMsg('Error al guardar datos'); // Status Bar
Raise Exception.Create('Error al guardar los datos'+#13+
'Mensaje del servidor: '+#13+e.Message);
End;
End;



¿ debo iniciar y finalizar transacciones para los accesos de sólo lectura ?

D7 + FB2 + MDO

Gracias

[Mick]

Como usas un Modo Read_Commited para las transacciones de solo lectura no necesitas abrirlas y cerrarlas, ya que esa transaccion vera las modificaciones confirmadas sin necesidad de abrirla y cerrarla.

Otra cosa seria que usases transacciones en modo snapshot table stability en las de lecturas, en ese caso tendrias que cerrarla y abrirla porque sino nunca veria las modificaciones de la base de datos realizadas posteriormente a su apertura.

Saludos

[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 :D

[sitrico]

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)

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]

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 :D

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

[Mick]

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

[reevil]

:eek: 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 ;)