Diferencias entre usar o no Transacciones

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

[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 Noteví]

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