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 (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.

4 thoughts on “Mal uso de las Transacciones”

  1. 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.

  2. 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.

  3. 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

  4. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.