¿Cuándo usar transacciones?

[santiago14]

Buenas, en principio no estoy seguro que esta duda vaya aquí pero, si no es así, que el moderador la ponga donde corresponda.
Resulta que tengo que hacer un desarrollo y estoy formando parte de un pequeño equipo de desarrollo. Bien, hasta aquí nada extraordinario. En una discusión de trabajo de esta mañana estábamos viendo algunas consultas a la BD (insert, update, delete, select y esas cosas), yo hablé un poco de las transacciones y de repente alguien del grupo me dice que "ellos no utilizan transacciones cuando se trata de hacer una consulta (el Select , se entiende), hubo ahí un entredicho respecto del tema y a mí me quedó la duda.
Ellos sostienen que no hace falta una transacción en ese caso porque el select no modifica el estado de la BD. Yo contesté, que si bien no hay modificaciones, hay conexión, hay cálculos y hay una respuesta.

Mi duda es simple: ¿Una transacción debe usarse siempre que se vaya contra una BD, o en los select's no hace falta?
Yo sigo sosteniendo que siempre hay que usarlas, pero... me quedó la duda con esto.

Saludos.

Santiago.

[Casimiro Notevi]

Por ejemplo, con Firebird + IBX: pones un componente IBDatabase y un componente IBTransaction, asociados entre ellos. Ajustas los parámetros y... por lo tanto, siempre estás usando transacciones.

Edito: mira esto y esto.

[mamcx]

En vez de adivinar, se investiga (cuando hay discusiones sobre el tema):


https://en.wikipedia.org/wiki/Isolat...tabase_systems)

En resumen: Depende del motor, metodo de conexion y libreria de acceso. Las transacciones y su aislamiento afectan tambien las lecturas.

[Neftali [Germán.Estévez]]

A priori, una transacción se utiliza para ejecutar de forma atómica un conjunto de operaciones que deben ejecutarse, o todas juntas o ninguna. Y además debe asegurar que durante el proceso el resto del sistema no puede acceder a los datos "intermedios" de esas operaciones.
Según esta definición, a priori, no tendría mucho sentido realizar una transacción en un SELECT.

El problema es que con el tiempo la cosa se ha ido complicando. Hay varios tipos de transacciones, generadas a partir de los bloqueos que producen, y diferentes formas de trabajar con ellas, en los diferentes SGBD's.

Casimiro ha comentado el sistema de trabajo de Firebird+IBX. Por ejemplo, el de SQLServer+ADO es diferente.
Las transacciones se inician manualmente y en los SELECT no es necesario realizarlas.

[Pericles]

Hola, para mi no tiene sentido utilizar transacciones para realizar consultas. Se deberian utilizar solamente cuando es necesario asegurar que se completen una serie de operaciones conjuntas sobre la base. Asegurando que se realizan las dos operaciones o se vuelve al estado anterior.

Por ejemplo..
reservar un pasaje para un usuario y luego cambiar el estado de butaca involucrada a "ocupado"
transferir dinero de una cuenta a otra, aumentanto el saldo de una +500 y disminuyendo el de la otra -500

Durante el comienzo de una transaccion se bloquean y duplican registros involucrados para poder realizar un rollback.
Una transaccion que incluya un SELECT podria llegar (mas que seguro) a ocupar recursos en la base para poder llegar a deshacer una supuesta operacion sobre los registros aunque sea solo lectura en este caso.

Espero haberme explicado.

Saludos
Nicolas Perichon

[Casimiro Notevi]

Empezado por Pericles

Hola, para mi no tiene sentido utilizar transacciones para realizar consultas. Se deberian utilizar solamente cuando es necesario asegurar que se completen una serie de operaciones conjuntas sobre la base. Asegurando que se realizan las dos operaciones o se vuelve al estado anterior.

Siempre deben usarse las transacciones, incluso en consultas. Imagina que estás sacando un informe de balance contable y mientras está la impresora ocupada, alguien añade/elimina/edita algún registro, te volverás loco para encontrar el fallo, deberás revisar todos los registros uno por uno para encontrar el "error" de cálculo, que no es ningún error.

Empezado por Pericles

Durante el comienzo de una transaccion se bloquean

Bueno, eso dependerá del SDBMS que uses. Con firebird no se bloquea nada (salvo que quieras hacerlo explícitamente)

[mamcx]

Empezado por Pericles

Hola, para mi no tiene sentido utilizar transacciones para realizar consultas....

Dicho de otra forma: No es lo que para *ti* tenga sentido, sino como opera y cuales son las reglas de cada motor de base de datos/app/operación de datos.

Aun cuando explicitamente no estes iniciando transacciones, el motor (o la libreria de acceso) *puede* que implicitamente lo haga.

Ahora bien, las transacciones cuando se lee no es que le des "BEGIN TRAN" para hacer un SELECT (probablemente el mismo motor hace eso implicito), es que entiendas como el modo de aislamiento esta afectando todo.

[Neftali [Germán.Estévez]]

Empezado por Casimiro Notevi

Imagina que estás sacando un informe de balance contable y mientras está la impresora ocupada, alguien añade/elimina/edita algún registro, te volverás loco para encontrar el fallo, deberás revisar todos los registros uno por uno para encontrar el "error" de cálculo, que no es ningún error.

No acabo de entender cual es el problema en la situación que comentas Casimiro.

Dejando de lado el motor y los componentes de acceso, creo que todos estamos de acuerdo en lo siguiente (si no, vamos a intentar concretarlo para saber de qué hablamos):

* Una transacción BLOQUEA la/s tabla/s que usa para escritura. Nadie puede escribir en esas tablas mientras la tabla está en uso.
* Todas las operaciones de una transacción se ejecutan de forma atómica.
* Al ser atómica y bloqueante, una transacción debe ser lo más rápida y pequeña posible.

Volvendo a lo comentado por Casimiro, yo creo que los SELECT no deben ir con transacciones (vuelvo a decir, independientemente de los que luego haga un SGBD o unos componente), porque no cumple nada de lo anterior:

+ Un SELECT (uno normal, al menos) no debe bloquear para escritura.
+ Un SELECT ya es de por sí, una operación atómica, unitaria.
+ Un SELECT no es precísamente (o no tiene porqué serlo) una operación rápida.

Otra cosa, y creo que por ahí nos estamos liando, es que un determinado proceso de SELECT (1 o varios), requiera que una determinada tabla (o varias) no se modifique/n, y eso podamos "corregirlo" o "solucionarlo" con una transacción, pero creo que no es el caso habitual.
Recordar también que una transación "añade" sobrecarga a una operación (más recursos, más tiempo, más proceso), por lo tanto, por definición, sólo debería usarse cuando sea estríctamente necesario.