¿Cuáles son los problemas de utilizar transacciones en una base de datos?

Question

De esta publicación.Un problema obvio es la escalabilidad/rendimiento.¿Cuáles son los otros problemas que provocará el uso de transacciones?

¿Podría decir que hay dos conjuntos de problemas, uno para las transacciones de larga duración y otro para las de corta duración?En caso afirmativo, ¿cómo los definiría?

EDITAR:El punto muerto es otro problema, pero la inconsistencia de los datos puede ser peor, según el dominio de la aplicación.Suponiendo un dominio digno de realizar transacciones (banca, para usar el ejemplo canónico), la posibilidad de un punto muerto es más como un costo a pagar para garantizar la coherencia de los datos, en lugar de un problema con el uso de las transacciones, ¿o no estaría de acuerdo?Si es así, ¿qué otras soluciones utilizaría para garantizar la coherencia de los datos y que estén libres de interbloqueos?

Answer 1

Depende mucho de la implementación transaccional dentro de su base de datos y también puede depender del nivel de aislamiento de transacciones que utilice.Supongo que aquí se trata de "lectura repetible" o superior.Mantener las transacciones abiertas durante mucho tiempo (incluso aquellas que no han modificado nada) obliga a la base de datos a conservar filas eliminadas o actualizadas de tablas que cambian con frecuencia (en caso de que decida leerlas) que de otro modo podrían desecharse.

Además, revertir las transacciones puede resultar muy caro.Sé que en el motor InnoDB de MySQL, revertir una transacción grande puede llevar MUCHO más tiempo que confirmarla (hemos visto que una reversión demora 30 minutos).

Otro problema tiene que ver con el estado de conexión de la base de datos.En una aplicación distribuida y tolerante a fallos, nunca se puede saber realmente en qué estado se encuentra una conexión de base de datos.Las conexiones de bases de datos con estado no se pueden mantener fácilmente ya que podrían fallar en cualquier momento (la aplicación necesita recordar qué estaba en el medio de la ejecución y rehacerla).Los sin estado pueden simplemente volverse a conectar y volver a emitir el comando (atómico) sin (en la mayoría de los casos) romper el estado.

Answer 2

Puede obtener puntos muertos incluso sin utilizar transacciones explícitas.Por un lado, la mayoría de las bases de datos relacionales aplicarán una transacción implícita a cada declaración que ejecute.

Los interbloqueos son causados ​​fundamentalmente por la adquisición de múltiples candados, y cualquier actividad que implique adquirir más de un candado puede bloquearse con cualquier otra actividad que implique adquirir al menos dos de los mismos candados que la primera actividad.En una transacción de base de datos, algunos de los bloqueos adquiridos pueden mantenerse más tiempo del que se mantendrían de otra manera; de hecho, hasta el final de la transacción.Cuanto más tiempo se mantengan los bloqueos, mayores serán las posibilidades de que se produzca un punto muerto.Esta es la razón por la que una transacción de mayor duración tiene mayores posibilidades de estancarse que una más corta.

Answer 3

Un problema con las transacciones es que es posible (improbable, pero posible) que se produzcan puntos muertos en la base de datos.Debe comprender cómo funciona, bloquea, realiza transacciones, etc., su base de datos para poder depurar estos problemas interesantes/frustrantes.

-Adán

Answer 4

Creo que el problema principal está en el nivel de diseño.¿En qué nivel o niveles dentro de mi aplicación utilizo transacciones?

Por ejemplo yo podría:

• Crear transacciones dentro de procedimientos almacenados,
• Utilice la API de acceso a datos (ADO.NET) para controlar las transacciones
• Utilice alguna forma de reversión implícita en una parte superior de la aplicación.
• Una transacción distribuida en (a través de DTC/COM+).

El uso de más de uno de estos niveles en la misma aplicación a menudo parece crear problemas de rendimiento y/o integridad de los datos.