¿Se necesita un comportamiento transaccional fuera de las bases de datos?

https://stackoverflow.com/questions/296909

08-07-2019
|

Pregunta

No me atrevería a hacer nada complejo en una base de datos sin transacciones. Casi siempre hay un comando incorporado fácil de usar. Pero cuando comienza a trabajar con otros datos persistentes, simplemente no obtiene este soporte de transacción fácil de usar. Algunos ejemplos son

sistemas de archivos
servicios web (ninguno que haya usado)

Incluso en datos no persistentes, a menudo es útil deshacer un bloque de trabajo, siguiendo una excepción. Ninguna de las estructuras de datos estándar que obtienes con un idioma admite transacciones.

Lo que me gustaría saber es, ¿por qué las bases de datos son el caso especial?

¿Hay enlaces útiles al tema del comportamiento transaccional fuera de las bases de datos?

Solución

Debo estar respetuosamente en desacuerdo: los sistemas transaccionales no son automática y exclusivamente motores de bases de datos, sino todo lo contrario ...

He implementado un mecanismo de transacción de aplicación (en .NET) que es distinto de una transacción de base de datos. En realidad es bastante fácil (unas pocas horas de trabajo, incluido un conjunto de pruebas unitarias). Está completamente escrito en C # sin dependencias de ninguna funcionalidad de base de datos o cualquier otro componente. Pero primero un poco de contexto ...

Esta característica de transacción que no es de base de datos existe en varias manifestaciones en la plataforma Java, como con EJB, ESB, JMS y, a menudo, en asociación con BPM. Algunas de estas manifestaciones usan una base de datos subyacente, pero no siempre y no por necesidad. Otras plataformas tienen manifestaciones comparables, como MSMQ.

La mayoría de los sistemas de control de versiones heredados NO implementan la semántica de transacciones ACID. Como dijo ddaa, CVS no, pero Subversion (su sucesor) sí. Visual Source Safe no lo hace. Si investiga Subversion, puede encontrar cuadros comparativos que lo señalen.

Ahora, para el punto crítico, una transacción de base de datos o su equivalente no garantiza una lógica empresarial segura. Aunque amo Subversion, es irónicamente un gran ejemplo de este hecho.

Puede usar Subversion religiosamente, junto con un script de compilación automatizado (un comando que compila, prueba y empaqueta su aplicación), y aún así confirma una compilación dañada en el repositorio de control de código fuente. Lo he visto repetidamente. Por supuesto, es aún más fácil con herramientas de control de fuente no basadas en transacciones ACID como VSS. Pero es sorprendente para muchas personas saber que es posible con herramientas como Subversion.

Permítanme, por favor, presentar el escenario Usted y un compañero de trabajo están desarrollando una aplicación y utilizando Subversion para el repositorio de control de código fuente. Ambos están codificando y ocasionalmente comprometiéndose con el repositorio. Realiza algunos cambios, ejecuta una compilación limpia (vuelve a compilar todos los archivos fuente) y todas las pruebas pasan. Entonces, comprometes tus cambios y te vas a casa. Su compañero de trabajo ha estado trabajando en sus propios cambios, por lo que también ejecuta una compilación limpia, ve pasar todas las pruebas y se compromete con el repositorio. Pero, su compañero de trabajo luego actualiza desde el repositorio, realiza algunos cambios más, ejecuta una compilación limpia y ¡la compilación explota en su cara! Revierte sus cambios, actualiza el repositorio nuevamente (solo para estar seguro), ¡y descubre que una construcción limpia aún explota! Su compañero de trabajo pasa las próximas dos horas solucionando problemas de la compilación y la fuente, y finalmente encuentra un cambio que realizó antes de irse que está causando la falla de la compilación. Le envía un correo electrónico desagradable a usted y a su jefe mutuo, quejándose de que rompió la construcción y luego se fue a su casa descuidadamente. Llegas por la mañana para encontrar a tu compañero de trabajo y a tu jefe esperándote en tu escritorio para maldecirte, ¡y todos los demás te están mirando! Entonces, rápidamente ejecuta una compilación limpia y les muestra que la compilación no está rota (todas las pruebas pasan, al igual que anoche).

Entonces, ¿cómo es esto posible? Es posible porque la estación de trabajo de cada desarrollador no es parte de la transacción ACID; Subversion solo garantiza el contenido del repositorio. Cuando su compañero de trabajo actualizó desde el repositorio, su estación de trabajo contenía una copia mixta del contenido del repositorio (incluidos sus cambios) y sus propios cambios no confirmados. Cuando su compañero de trabajo ejecutó una compilación limpia en su estación de trabajo, estaba invocando una transacción comercial que NO estaba protegida por la semántica de ACID. Cuando revirtió sus cambios y realizó una actualización, su estación de trabajo coincidió con el repositorio pero la compilación todavía estaba rota. ¿Por qué? Debido a que su estación de trabajo también era parte de una transacción comercial separada que tampoco estaba protegida por la semántica de ACID, a diferencia de su compromiso con el repositorio. Como no ha actualizado su estación de trabajo para que coincida con el repositorio antes de ejecutarlo

Otros consejos

Creo que la razón por la que las transacciones solo se ven en las bases de datos es que, por definición, los sistemas que proporcionan transacciones se denominan bases de datos. Eso suena circular, así que debo explicarlo.

El soporte de transacciones es la característica que proporciona propiedades ACID . En términos simples, eso significa que una transacción es algo que permite 1. agrupar una serie de operaciones discretas en un paquete que tiene éxito como un todo o falla en su conjunto 2. ocultar cambios no confirmados a usuarios concurrentes, de modo que 3. usuarios concurrentes tener en todo momento un "consistente" vista del sistema.

Los sistemas de archivos tradicionalmente ofrecen algún mecanismo de bloqueo, pero esto es diferente de proporcionar transacciones. Sin embargo, todos los sistemas de archivos tienen algunas propiedades atómicas. Por ejemplo, si tiene los directorios / a / y / b / , y al mismo tiempo intenta realizar mv / a / b / a y mv / b / a / b , solo una de esas operaciones tendrá éxito, sin comprometer la integridad. Sin embargo, lo que generalmente carece de sistemas de archivos es la capacidad de agrupar múltiples operaciones en un solo paquete atómico aislado.

Una respuesta mencionó Subversion. Todos los sistemas de control de versiones sanos tienen transacciones. Cuando se compromete con varios archivos, el sistema aplica el compromiso por completo o lo rechaza por completo (excepto CVS, que no considero sano). La causa del rechazo es siempre un cambio concurrente. Los implementadores del sistema de control de versiones son muy conscientes de mantener una base de datos.

Otra respuesta mencionó los sistemas de mensajería mencionados como transaccionales . No leí el material vinculado, pero la respuesta en sí misma solo mencionaba la entrega atómica de mensajes. Eso no son transacciones.

Nunca supe de Clojure antes de Brian C. lo mencionó aquí. Me parece que es una implementación de transacciones fuera del contexto de una base de datos. Aquí el enfoque es el control de concurrencia, en lugar de mantener la consistencia de los datos duraderos.

Entonces, con la excepción de Clojure, parece que cualquier sistema que necesita transacciones usa una base de datos subyacente o se convierte en una base de datos.

Los sistemas de archivos modernos tienen transacciones. Son transparentes para el usuario final.

NTFS, XFS, JFS, EXT3 y ReiserFS lo hacen, solo por nombrar algunos.

Y eso es solo interno al sistema de archivos. Muchos sistemas operativos también admiten el bloqueo de archivos (ver flock (2) en el mundo * NIX, por ejemplo) con bloqueos exclusivos (escritura) y compartidos (lectura).

Editar: Si lo piensa, los sistemas de archivos no tienen niveles de aislamiento como los DB modernos porque una vez que termina de leer un archivo, tradicionalmente lo cierra si no lo bloqueó. Luego lo vuelves a abrir cuando quieres escribirle.

Clojure utiliza Memoria de transacciones de software , que utiliza transacciones para que sea fácil y seguro escribir programas de subprocesos múltiples sin bloqueos manuales. Clojure tiene estructuras de datos inmutables con referencias mutables a ellas, y se requieren transacciones para cambiar las referencias.

Los sistemas de mensajería son otro ejemplo de administradores de recursos transaccionales.

Es decir, puede asegurarse de que un consumidor de mensajes procese con éxito un mensaje de la cola. Si el procesamiento falla, el mensaje se deja en la cola.

Además, un sistema de mensajería puede participar en una transacción distribuida con otro administrador de recursos.

Más información en

Los commits de Subversion son transaccionales: son verdaderamente atómicos, por lo que un commit interrumpido no deja el repositorio en un estado inconsistente.

Tuve la situación que necesitaba para tratar un sistema de archivos y una base de datos como una unidad transaccional.

En mi caso, solo necesitaba descargar un conjunto de archivos en el sistema de archivos. Lo hice creando directorios aleatorios cada vez, colocando los datos allí y almacenando el nombre del directorio en una tabla de base de datos. Por lo tanto, todo el trabajo de mi base de datos, y el nombre del directorio en la tabla de la base de datos (= trabajo del sistema de archivos), podrían realizarse en una transacción de la base de datos.

http://www.databasesandlife.com/atomic-operations -over-filesystem-and-database /

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow