04.04.08
Mal uso de las Transacciones
Una transacción permite que al realizar una acción determinada, el estado de la entidad o entidades a las que estemos atacando se mantenga como al principio en el caso de que se produzca algún tipo de error en la transacción.
Un típico ejemplo de transacción es la que realizamos contra un cajero automático.
1) Introducimos cantidad a retirar
2) Introducimos nuestra identificación
3) Se resta la cantidad a retirar de la cuenta corriente
4) El cajero extrae los billetes para que los cojamos
Si tras el paso 3 ocurre un error en la aplicación y todos estos puntos no se llevan a cabo de manera transaccional veríamos como en nuestra cuenta se ha restado el efectivo, pero nunca recibiríamos los billetes físicamente. En cambio, en un ámbito transaccional todo volvería a su estado inicial, quedando el efectivo de la cuenta intacto.
Hasta aquí nos ubicamos con el concepto de transacción y ahora vienen las malas prácticas al respecto.
1) La primera y obvia es no utilizar transacciones cuando trabajamos en un contexto como el que hemos citado con el ejemplo. Los datos se perderán o quedarán inconsistentes.
2) Es un error realizar una transacción cuando únicamente realizamos consultas a la base de datos. No hay cambios en la misma, no tiene sentido volver a un estado anterior porque nada a cambiado.
3) No tiene sentido utilizar una transacción si se realiza una consulta y una modificación (inserción, actualización, borrado…). Si el error se produce en la modificación no va a pasar nada porque la primer consulta no cambió nada de la base de datos.
Saludos.
Miguel.
Hendrixo said,
May 21, 2008 at 1:26 pm
Tu artículo es incorrecto una de las características de las transacciones es la del bloqueo de registros o tablas, y este concepto varia la idea de tu artículo.
Miguel said,
May 21, 2008 at 2:37 pm
Hola Hendrixo,
En el caso de no estar usando transacciones si fallamos después del paso 3 (es decir, la actualización del efectivo ya se ha realizado) nos habremos quedado sin él.
Si usamos transacciones tras el error del paso 3 todo vuelve a su estado inicial.
¿Podrías ampliar un poco más el apunte que incluyes? He revisado el artículo y no veo dónde encaja la casuística del bloqueo de registros y tablas en el ejemplo.
Gracias por tu aportación.
Miguel.
Sanas said,
May 5, 2010 at 1:49 pm
Yo creo que Hedrixo se refería a que muchas veces, nos interesa provocar bloqueos de tablas frente a las consultas o modificaciones concurrentes que puedan estar realizando otros usuarios.
Por ejemplo: Yo voy a consultar y en funcion de ello posteriormente modificar. Me interesa que sea transaccional provocando que la primera tabla consultada quede bloqueada a otras instrucciones para que mi modificación sea consistente.
Por tanto, yo también creo que los ptos 2 y 3 son incorrectos.
Salu2