Diferencias entre usar o no Transacciones

[roman]

Pues yo creo que depende de muchas cosas. Es posible que por la naturaleza del sistema, los usuarios no se "estorben" unos a otros de manera que casi se pueda considerar una aplicación monousuario.

Te voy a dar un ejemplo concreto, en el que no puedo vivir sin transacciones.

Yo manejo inscripciones a cursos escolares y en época de inscripciones la demanda es muy fuerte. Un alumno ingresa al sistema y se le presenta una lista de los grupos disponibles, esto es, de los que aún tienen lugares. El alumno escoge uno y se procede a la inscripción, que consta, básicamente de dos operaciones:

1. Se inserta un registro en una tabla de inscripciones
2. Se disminuye un lugar en el grupo donde se inscribió.

Todo muy sencillo. Pero toma en cuenta que entre el momento en que el alumno ve la lista de grupos y el momento en que da click en el grupo deseado, otros alumnos pudieron haber seleccionado el mismo grupo y agotado los lugares. Eso es bastante probable, al menos en mi caso, porque estamos hablando de cientos de accesos simultáneos al sistema.

Si lo dejo pasar tal cual, estaría sobrellenando el grupo. Entonces lo que hago es meter esas dos operaciones en una transacción. Una vez que decremento el número de lugares, vuelvo a ver el cupo, si éste es negativo, es porque ya se habían agotado los lugares. Entonces hago un rollback y le mando un mensaje al alumno.

Yo realmente no manejo mucho el tema, pero creo que se puede resumir así: en una transacción debes poner aquellas operaciones en donde no puede fallar ninguna, o todas son exitosas o todas fallan. Si tienes una situación así, entonces debes usar transacciones.

// Saludos

[MaMu]

Podria decirse que al usar transacciones lo que busco es lograr "conciliar" las operaciones de datos entre usuarios?

Saludos

[[kuan-yiu]]

Las transacciones son la forma más sencilla de encadenar operaciones sobre la BD que no se puedan hacer de forma independiente.
Si yo tengo que ejecutar A,B y C siempre en ese orden y siempre todas o ninguna es mucho más sencillo, claro y mantenible meterlas en una transacción que mediante if-else revisar si todo ha ido bien, si puedo continuar... Yo lo veo como una forma de ahorrar comprobaciones.

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

Empezado por kuan-yiu

...y siempre todas o ninguna

Yo creo que esa es la clave.

Adicionalmente te pueden servir utilizando diferentes "Isolation Level" para resolver algunos problemas de bloqueos entre los usuarios.
Es un tema que ya hemos discutido otras veces, y recuerdo uno de los últimos hilos que estaba muy interesante.

[MaMu]

Empezado por Neftali

Yo creo que esa es la clave.

Adicionalmente te pueden servir utilizando diferentes "Isolation Level" para resolver algunos problemas de bloqueos entre los usuarios.
Es un tema que ya hemos discutido otras veces, y recuerdo uno de los últimos hilos que estaba muy interesante.

Claro, en el caso mi aplicación, nunca puede porducirse que dos o mas usuarios modifiquen un registro al mismo tiempo. Pero estoy por desarrollar una en la que posiblemente, sean varios usuarios quienes posiblemente intenten editar un registro al mismo tiempo.

[[kuan-yiu]]

Entonces no te la jueges. Puede que al final nunca tengas accesos concurrentes pero lo mejor es programar como si los hubiese.

[cascarrabias]

Lo que te comentan los companieros es muy cierto...el punto esencial de una transaccion es que engloba multiples operaciones en un solo paso(todo o nada).

Tampoco debes olvidar, no solo hablando de muchos usuario, incluso pensando en uno solo haciendo una insercion de registros en digamos 3 tablas si por hazares del destino ocurre una falla en la insercion de una de las tablas (porque hasta errores improbables sucede) y solo lograste hacer la insercion en 2 y en la tercera no...ya vas a tener informacion inconsistente... te dejo este ejemplo muy sencillo pero util.....

Considere la base de datos de un banco que contiene balances para varias cuentas de clientes, supongamos que queremos registrar el pago de $100 desde la cuenta de Alice hacia la cuenta de Bob, las sentencias SQL a ejecutar para esta operacion serian como la siguiente:

Código SQL [-]
UPDATE cuentas SET balance = balance - 100 WHERE nombre = ‘Alice’;
UPDATE branches SET balance = balance - 100 WHERE nombre = (SELECT branch_name FROM cuentas WHERE nombre = ‘Alice’);
UPDATE cuentas SET balance = balance + 100 WHERE nombre = ‘Bob’;
UPDATE branches SET balance = balance + 100 WHERE nombre = (SELECT branch_name FROM cuentas WHERE nombre = ‘Bob’);

Como se puede observar hay varias actualizaciones involucradas para terminar la operacion, los operadores del banco deben estar seguros de que todas esas actualizaciones se ejecuten, o en caso de falla que ninguna se ejecute, ya que se podria dar el caso de que Bob reciba $100 sin que sean debitados de la cuenta de Alice. Agrupando las actualizaciones en una sola transaccion se puede garantizar que en caso de un fallo ninguna actualizacion se ejecute.

[[AzidRain]]

Las transacciones no necesariamente son útiles solo para manejar concurrencia. Son útiles cuando necesitas ejecutar varias instrucciones para llevar a cabo una tarea. Por ejemplo:

1.- Insertar un registro en la tabla de facturas
2.- Insertar un registro por cada linea de detalle de la factura
3.- Insertar un registro correspondinete a la factura pero en la tabla de cuentas cobrables.

Supongamos que esto lo hacemos sin transacciones y se presenta un error (cualquiera) al momento de ejecutar 2 o 3. Es obvio que tendríamos que deshacer los cambios realizados en los pasos anteriores. Con las transacciones esto se resuleve sencillamente metiendo todo lo que pueda fallar en un try..except y ejecutando un rollback si hay error, de manera que si algo falla no se modifica nada de las tablas.

Un apunte, en el caso de MySQL si utilizas una tabla con campos autoincrementables al solicitar un número en una tabla dentro de una transaccion el campo se incrementa normalmente para cuando se requiera otro número, pero si la transacción se aborta con un rollback ese número autogenerado ya no se recupera en la tabla por lo que quedan huecos en la secuencia.

Por ejemplo:

1- Abrimos la transaccion.
2. Abrimos la tabla facturas que tiene un campo folio tipo autoinc que en este caso va a valer 1.
3.- Guardamos nuestros datos.
4.- Fializamos la transacción.

Ahora abrimos otra transaccion.
Solicitamos un nuevo folio (nos devuelve 2)
Ocurre un error y hacemos rollback.

Abrimos una nueva transaccion.
Solicitamos un nuevo folio...y nos devuelve 3!!

En este caso el 2 se perdió en la transacción abortada aunque no afecta por que no hay forma de que otra transacción obtenga exactamente el mismo número.

[Casimiro Noteví]

Lo que comentas sobre los campos autoincrementales es el método habitual de funcionamiento en la mayoría de bases de datos.
Para llevar un control de números "sin huecos" es necesario usar otras técnicas.