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 (aunque aquí incluyo un matiz que podréis ver en los comentarios de ese post, que podrían darse casos donde por el contexto de vuestro aplico necesitéis bloquear la tabla con una transacción para que las modificaciones que realicéis después de vuestra consulta no se vean afectadas por otras llamadas concurrentes a las tablas con las que trabajais).
Saludos.
Miguel.
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.
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.
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
Hola Sanas, Hendrixo,
Entiendo el caso que comentáis que en un momento dado puedo necesitar bloquear el contenido de la tabla mediante una transacción, pero entiendo también que en los ejemplos que indicáis (consultar y en función de ello modificar):
* en el caso 2 no aplica, ya que como marca el ejemplo, estamos en un escenario que exclusivamente consultamos y no realizamos ningíºn tipo de acción adicional ni toma de decisión (normalmente se dan casos de este estilo cuando en su día si hubo modificaciones en la transacción pero fueron eliminadas y el desarrollador por error se dejó la transacción).
* en el caso 3, tienes razón, pueden existir estos casos, modifico el artículo para dar cobertura a este matiz
Muchas gracias a ambos por las explicaciones.
Un saludo.