Optimización de aplicaciones en Cliente/Servidor (4/6): Transacciones

Cada vez que realizamos una operación que implique escritura en disco estamos realizando una transacción. Cuando lanzamos procesos que transaccionen nos encontramos con dos casos extremos:
Puede que forcemos muchas transacciones pequeñas, lo que implica:

• Abrir y cerrar cada una de las transacciones, lo que provoca un tiempo de retardo por cada operación (desventaja).
• Dar de alta un registro en el historial del servidor por cada transacción realizada, que también implica retardo (desventaja).
• Bloqueamos pocas fichas, de modo que apenas gastamos memoria en el servidor (ventaja), pero esto no siempre nos interesa. Supongamos, por ejemplo, un proceso en el que para una factura de un cliente realizamos una transacción por cada albarán, y justo cuando hemos facturado la mitad se cae el sistema. ¡Nos queda la otra mitad sin facturar y las transacciones que ya se han realizado no se deshacen! En casos como éste es aconsejable realizar una transacción por cada factura del cliente que englobe todos los albaranes.

Puede que forcemos una sola transacción grande, lo que implica:

• Un gasto considerable de memoria en el servidor (desventaja), ya que éste guarda en memoria las fichas bloqueadas por si hay que deshacer la transacción. Ojo: hay gasto de memoria cuando realizamos bajas o modificaciones, pero no cuando damos altas, ya que en este caso no hay ficha que memorizar por si hay que deshacer la transacción. Caso aparte son aquellas altas que desencadenan actualizaciones, ya que en este caso las fichas modificadas por la actualización sí se guardan en memoria.
• La velocidad a la que se realizan las operaciones es mucho mayor que en el primer caso (ventaja).
• Se genera una sola transacción, de modo que la pérdida de tiempo es mucho menor (ventaja).
• Se bloquean las fichas implicadas en la operación, lo que impide a otros usuarios de la aplicación trabajar con esas fichas (desventaja). No se bloquean todas las fichas a la vez, sino que se van bloqueando según trabajamos con ellas. Es decir, si en una transacción vamos a modificar 1.000 fichas, cuando llega a la 563 habrá bloqueado las primeras 563.

Etiquetas: aplicacion optimizada, optimizacion c/s, transacciones