Diferencias entre usar o no Transacciones

[MaMu]

Como bien dice el título, me gustaria que alguien a groso modo me explicase la diferencia entre usar transacciones o no en el diseño de una aplicacion de base de datos, multiusuario, basándose en que seria desarrollada con Delphi7 empleando como engine mySQL 4.1.

Pregunto esto, porque hice una aplicación sin usar transacciones y actualmente la usan 25 usuarios en simultáneo y hace ya más de un año que no ha habido ningun error, ningun problema.

Saludos y gracias

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

[MaMu]

Los ejemplos de roman y cascarrabias me han sido muy utiles para apreciar el objeto de una transacción.
Ahora bien,

1) Cuándo debo iniciar la transacción?
2) Cómo debe finalizar?
3) Es el engine quien se encarga de negociar la conciliación de datos?
4) Si tengo un error, utilizo RollBack, pero como se cuando es exitosa?

Saludos

[[maeyanes]]

Hola...

Te contesto de acuerdo a mi experiencia:

Empezado por MaMu

1) Cuándo debo iniciar la transacción?

Una transacción la debes iniciar justo antes de mandar los datos a la base de datos:

Código Delphi [-]
Transaction1.StartTransaction;
DataSet1.Post;
DataSet2.Post;

2) Cómo debe finalizar?

Mayormente con Commit o Rollback, esto de acuerdo al resultado de las operaciones...

3) Es el engine quien se encarga de negociar la conciliación de datos?

Si te refieres a la integridad de los datos, mayormente se verifican en la parte del servidor mediante reglas de integridad referencial, disparadores y procedimientos almacenados.

Si alguna de estas operaciones de verificador terminan en un error, el servidor se encarga de comunicar al cliente de tal situación...

4) Si tengo un error, utilizo RollBack, pero como se cuando es exitosa?

Saludos

Usando la captura de excepciones:

Código Delphi [-]
Transaction.StartTransaction;
try
  DataSet1.Post;
  DataSet2.Post;
  Transaction.Commit
except
  Transaction.Rollback;
  ShowMessage('Ocurrió un error')
end

Espero que te aclare un poco tus dudas...


Saludos...

[[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 Notevi]

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.

[danilo_candales]

Quizas no es la definición mas completa, pero puede dar una idea bastante clara de que significa una transaccion y sus principales caracterisicas.

http://es.wikipedia.org/wiki/ACID

Saludos,

[[Delphius]]

No estaría demás aclarar algo que ya fue dicho implícitamente: estructurar las tablas y emplear las transacciones de la manera más simple posible.

Si bien lo "simple" es un término subjetivo... por lo general significa:
1. Ser lo más breve posible, y (o bien)
2. Que involucre la menor cantidad de tablas y/o registros posibles para llevar a cabo la consistencia de información.

No es lo mismo llevar una transacción de 30 registros en 5 tablas que llevar una transacción de 5 registros en 30 tablas.

Como también no es lo mismo llevar abierta una transacción durante media hora en un negocio de poco movimiento para atender a 5 clientes durante todo el día, que llevar un negocio de todo 24 hrs en donde en esas 24 hrs se atienden a cientos o miles de personas.

El ejemplo de Roman y el de cascarrabias me hicieron acordar que hace unos días tuve que ir al banco a pagar los impuestos mensuales, como lo ha hecho ese mismo día muchas de las otras personas que he visto en cola. La cuestión es que estuve una hora parado para ser atendido, la cola era larga (unas 20 personas antes que yo). Veamos el escenario:
Cajero: Femenino
Edad aproximada: 50 años
Tiempo promedio de servicio: 6 minutos

Llevaba media hora y la gente impaciente se empezó a ir... unas 3 o 4 he contado. Un poco de matemática: a 6 min por persona durante media hora son 5 personas. Más el peor caso de desertores (3) nos da 20 - 8 = 12.
una vez atendida la quinta persona, la cajera se fue (vaya a saber porqué) y se sentó un señor.
Edad aproximadada: 40 años
Tiempo promedio de servicio: incalculable, simplemente rápido.

La cuestión es que esta cajera se demoró media hora en atender a 5, pero esta otra persona atendió a 13 personas en esa media hora restante (yo incluído).

Dos preguntas:
¿Aplicarías transacciones en este esquema?
Si tu respuesta es un si ¿Cuando iniciarías la transacción? ¿Ni bien llega el cajero?.... Si atiende esta cajera e iniciamos la transacción ni bien se acerca el cliente tendríamos la transacción abierta durante 6 minutos. Si lo hacemos con el cajero... ¡pues saquemos cuentas!

En otros escenarios, o modelos tal vez la situación es diferente: emplear transacciones es una pérdida de tiempo porque simplemente no se llevan en práctica. Ya sea porque la probabilidad de un acceso recurrente es muy baja (1) o porque simplemente la propia naturaleza del negocio demuestra que no hay motivos de acceso recurrente (algo raro pero quien sabe... en alguna de esas existe).

Lo cierto es que el tema de las transacciones puede requerir de un análisis de un día como de una hora.

(1) Por ejemplo ahora se me ocurre la situación de la mueblería que esta cerca de casa: Por lo general sus empleados están ociosos y el estar en una calle sin salida, media oculta y con poco tráfico hace que la demanda de clientela sea muy baja.
No todos los días la gente compra y repara muebles y por lo general se trata de un negocio que no tiene demasiado movimiento. Siendo honesto, con suerte ese negocio debe ser visitado cuanto mucho 3 o 4 veces al día, no he visto gente allí (no me extraña que esté casi en quiebra).

Y una pregunta boba, ¿conlleva alguna utilidad realizar transacciones cuando se trata de una aplicación monousuario?

A lo que voy es que aplicar transacciones es útil cuando se demuestra que existe una probabilidad mediana de un acceso y uso recurrente.

Esto de las probabilidades me gusta... el ejemplo que se ha puesto aquí con lo dicho por Ian Marteens me hace acordar sobre preguntas filosóficas: ¿Que tan probable es que Pepito desee sacar dinero de su cuenta y que al mismo instante de tiempo Juancito le está haciendo un depósito? ¿Y si se trata de que Pepito realiza una consulta de saldo? ¿Se puede? ¿Y que sucede?

No me hagan caso... es que ando medio enojado todavia con aquella cajera por no atender rápido. ¡Que lo tiró!

Saludos sin transacciones: este mensaje fue escrito en 40 minutos!

[[Lepe]]

La probabilidad de desaguisados, incluso en monousuario, es alto (lo que decía AzidRain). Si se puede, mejor usar transacciones.

Lo peor si cabe, es aprender a usarlas, después intuitivamente se implementa.

Saludos

[Casimiro Notevi]

Por supuesto, hay que usar transacciones siempre.
Siempre que exista peligra de provocar incoherencias con los datos.
No se trata solamente de la concurrencia multiusuario, no es eso, se trata de mantener siempre la coherencia de los datos, me explico con la tienda de muebles que hay junto a la casa de Delphius:
Delphius está cansado de la silla que usa para trabajar con su ordenador, está ya muy vieja, el asiento es durísimo y no puede aguantar más de 10 minutos seguidos sin tener que ponerse de pié a descansar sus posaderas, así que un día se dice: "¡se acabó!", le da una patada y la rompe, abre su hucha y saca todos sus ahorros, cree que le alcanza para una nueva. Agarra la silla rota, sale a la calle, la deja junto al contenedor de la basura y se mete en la tienda de muebles.
No tiene que esperar cola porque no hay nadie más a quien atender, ve una silla que le encanta, la prueba, es supercómoda además de bonita y no muy cara, le alcanza con sus ahorros, así que decide llevársela.
El dependiente de la tienda anota la venta en su obsoleto ordenador mientras le explica a Delphius que ha tenido suerte, que es la única silla que le quedaba de ese modelo y que ya no traerá más porque no se fabrica.

Nueva factura >> artículo: "Silla especial para programadores" >> cantidad: 1 >> precio: 30$ >> "aceptar"...
El viejo ordenador, un IBM PC con un intel 8088 a 4 Mhz, 640 Kb de ram, (nunca nadie necesitará más) comienza a ronronear su disco de 20 Megas. En la pantalla fósforo verde se puede leer:

>Creando factura... creada.
>Anotando importe en caja... anotado.
>Actualizando inventario... ¡¡¡ Pluuufff !!!, se ha ido la luz.

El "¡¡¡ Pluuufff !!!, se ha ido la luz." no lo ponía en la pantalla, es lo que sucedió. Vaya contrariedad.

Mientras espera que vuelva la luz, Delphius le explica al dependiente que si tuviera un SAI (UPS) hubiera podido acabar de hacer la factura y luego haber apagado el ordenador sin peligro.
Ante la tardanza, Delphius, mientras tanto, se entretiene mirando una mesa con soporte retráctil para el teclado, el precio le asusta, tendrá que ahorrar bastante tiempo, de momento deberá conformarse con la silla únicamente.
Por fin, ya vuelve la luz, el dependiente enciende el ordenador y hace una verificación de los datos que presenta en pantalla:

Ventas del día
-----------------------------------
Factura nº : 234
Referencia : SILLA001
Descripción: Silla para programador
Cantidad...: 1
Precio.....: 30$


Arqueo de caja
---------------
Caja nº ..: 1
Factura nº: 234
Importe ..: 30$
Total caja: 30$


Inventario artículos
------------------------------------
Referencia..: SILLA001
Descripción : Silla para programador
Stock actual: 1

Aquí vemos que hay una inconsistencia en la base de datos, (además de que indica que debe existir 30$ que no ha cobrado todavía) dice que ha vendido la silla que quedaba y, sin embargo, también dice que hay una silla en el stock.
Delphius le explica al dependiente que eso le ha ocurrido porque el programa de ventas que está usando, de la empresa moco$oft es bastante malo y no usa transacciones, el dependiente lo escucha pero no lo oye, está pensado en cómo arreglar el problema antes de que llegue el dueño de la tienda y le eche la culpa a él de no saber usar el ordenador y de haberse apropiado de 30$ que realmente no ha cobrado todavía.
Delphius, que además de ser una buena persona es un afamado programador se ofrece a ayudar al pobre tipo y usando técnicas de hacker, un programa descompilador, un depurador de ensamblador y un conjuro que le enseñó un chamán amigo de su tía Hermenegilda... finalmente consigue añadirle transacciones al programa (es que este Delphius es tremendo) y lo deja así:

var
__iNumFactura:integer;
begin
__try
____StartTransaction;
____iNumFactura := HacerFacturaNueva(now); // crea la factura
____CobrarFactura( iNumFactura ); // hace el apunte en caja
____DescontarInventario( iNumFactura ); // descuenta el artículo del inventario de artículos
____Post;
____Commit;
__except
____Rollback;
__end;
end;

El dueño de la tienda, en agradecimiento, contrató a Delphius para hacer una nueva gestión comercial para su cadena de tiendas por todo el país, tendría que conectar en tiempo real decenas de tiendas, él sería el jefe del departamento de informática, tendría a su cargo una gran cantidad de programadores y... bueno, eso es otra historia.


Moraleja: usa transacciones si no quieres quedarte sin silla

[[Delphius]]

Amigo Casi, me encantó la historia.
Me he reído bastante

Creo que con ello completas y das a entender el uso de las transacciones. Yo andaba buscando la manera de darle un aspecto un tantito irónico a mi cuento de la vida real. Me quedo con tu historia

Saludos,
PD: Por cierto, la silla que uso si bien es un tanto viejita es muy cómoda. Aunque admito que de vez en cuando me reclino y pongo los pies sobre el escritorio.

[[AzidRain]]

Mi buen Delphius ya lo acaba de decir el buen Casi...

Las transacciones, fuera de lo que se podría pensar, fueron diseñadas para mantener a toda costa la integridad de los datos no tanto para la concurrencia. Digamos que esto fue un efecto adicional.

Ahora respecto a tus dudas...

En el caso del POS que ejemplificas:

1.- Una transacción solo comienza cuando:
El operador (cajero) escanea o digita un producto desde que se terminó la última transacción.
2.- Una transacción solo termina cuando:
El operador entrega el cambio al cliente (previo cálculo del sistema)

En los sistemas de POS además de todo ello hay que considerar que el operador debe ser capaz de seguir cobrando (como sea) aun y cuando no tenga comunicación con el servidor (ah verdad) y ahi es donde viene el chiste del asunto de los POS.

El enfoque de IBM en su ya viejo SO especial para POS prácticamente es un estandar mundial ya que es muy confiable y evita este tipo de problemas (aun y cuando los displays no se ven bonitos ni nada de esas jaladas que muchos nos inventamos). Ese sistema es ROBUSTO con mayúsculas ya que prácticamente tienes que destruir todo para que no haya forma de recuperarse de algún problema. Y el enfoque que usaron ellos: simple....KISS

[MaMu]

A ver, a ver:

Código Delphi [-]
var
__iNumFactura:integer;
begin
__try
____StartTransaction;
____iNumFactura := HacerFacturaNueva(now); // crea la factura
____CobrarFactura( iNumFactura ); // hace el apunte en caja 
____DescontarInventario( iNumFactura ); // descuenta el artículo del inventario de artículos
____Post;
____Commit;
__except
____Rollback;
__end;
end;

Si se me corta la luz, me anula la transacción?, porque la verdad esa parte no la entendi, porque que pasa si se corta la luz justo en el instante del post, lo otro lo entendi, pero esto, la verdad que no.

[Casimiro Notevi]

Empezado por MaMu

A ver, a ver:
Si se me corta la luz, me anula la transacción?, porque la verdad esa parte no la entendi, porque que pasa si se corta la luz justo en el instante del post, lo otro lo entendi, pero esto, la verdad que no.

No es que te anule la transacción, lo que ocurre es que los datos no se guardan "realmente" hasta que confirmas (commit) la transacción.
Te recomiendo que leas esto y el tema sobre transacciones de este libro, seguro que así te queda claro.