Cómo garantizar la integridad de los datos en aplicaciones empresariales con múltiples usuarios - Patrón de Bloqueo y Demarcación de Transacción

Introducción :-

La mayoría de las aplicaciones empresariales son accedidas por muchos clientes simultáneamente y el desarrollador debe proporcionar tanto funcionalidad como rendimiento a los usuarios. Con eso en mente, ¿cómo aseguramos que la consideración por el rendimiento no comprometa la integridad de los datos? Es decir, se necesita un mecanismo para manejar múltiples usuarios accediendo a los datos de manera concurrente.

Las aplicaciones empresariales a menudo intentan equilibrar la escalabilidad de la aplicación con consideraciones de concurrencia. Se puede lograr escalabilidad utilizando diferentes técnicas, incluyendo minimizar el tráfico de red.

Este artículo describe el patrón de Bloqueo en dos partes. La Parte 1 del artículo explica una visión general transaccional, demarcaciones de transacción y luego describe en detalle la Demarcación de Transacción Gestionada por Contenedor.

La Parte 2 del artículo explica las metodologías de bloqueo, cómo se implementa en el Motor SAP J2EE de WAS y cómo resuelve los problemas de concurrencia.

Visión general transaccional :-

Las transacciones representan una unidad fundamental de trabajo para administrar la complejidad empresarial. En su forma más básica, una transacción es una serie de operaciones que parecen ejecutarse como una única operación atómica grande. Una aplicación empresarial típica tiene muchas transacciones asociadas. Una vez que la transacción comienza, termina con un commit o un aborto.

Las transacciones garantizan la integridad de las reglas comerciales de una aplicación, un proceso que da lugar a aplicaciones de procesamiento de transacciones (TP) que ejecutan múltiples transacciones simultáneamente. Las transacciones permiten a múltiples usuarios compartir los mismos datos y garantizan que cualquier conjunto de datos que actualicen se actualice completamente sin que otros clientes interfieran para modificarlo.

Como ejemplo de aplicación, considera un sistema de reserva de billetes de tren. En nuestro ejemplo, cuando un pasajero quiere reservar un asiento, se deben realizar las siguientes acciones en secuencia: • Debe existir un asiento disponible • Se debe emitir un billete • El pasajero debe ser facturado a través de una tarjeta de crédito utilizando el Intercambio Electrónico de Datos (EDI) • Ese asiento debe eliminarse de la lista de asientos disponibles. Este sistema plantea rápidamente preocupaciones de concurrencia, escalabilidad y consistencia cuando múltiples usuarios intentan hacer reservas en un sistema distribuido.

Para simplificar la complejidad potencial, considera todo el proceso de reserva de tren como una unidad de trabajo: una transacción. Una transacción comprende cuatro propiedades críticas: • Atómica • Consistente • Aislada • Duradera

Juntas, las cuatro propiedades críticas producen el acrónimo ACID.

En el contexto de nuestro ejemplo, considera una transacción atómica si se ejecuta completamente o no del todo. Por ejemplo, si no existe un asiento, la transacción completa se aborta o retrocede al inicio de la transacción. Cuando una transacción retrocede, la base de datos vuelve al estado que tenía antes del inicio de la transacción. La atomicidad garantiza que muchas operaciones estén vinculadas y aparezcan como una unidad de trabajo contigua.

Pasando a la aislamiento, considera una transacción aislada si la transacción se ejecuta de forma serial. En otras palabras, debería parecer como si la transacción se ejecutara sola sin que ocurra otra transacción simultáneamente. Esto garantiza la integridad de los datos. Durante las transacciones, se asignan bloqueos a los datos automáticamente según sea necesario. Si una transacción mantiene un bloqueo en los datos, entonces el bloqueo evita que otra transacción manipule los datos de forma concurrente hasta que se libere el bloqueo.

Una transacción también debe ser duradera; un registro permanente de la transacción debe persistir. Debe garantizar que las actualizaciones a recursos como la base de datos sobrevivan a los fallos del sistema. Con fines de optimización, los registros transaccionales a menudo se mantienen en memoria. Sin embargo, la transacción no puede considerarse ACID hasta que los datos se escriban en almacenamiento permanente.

Aunque es el segundo en la lista, el último término de una transacción ACID a considerar es consistente. Una transacción asegura la consistencia si es atómica, aislada y duradera. Si un tren tiene 100 asientos y cada asiento se vende por $100, entonces al final de 10 transacciones exitosas la cuenta del ferrocarril debería tener $10000 más de lo que tenía al inicio. Si este es el caso, la base de datos está en un estado consistente. Otro ejemplo puede ser que una cuenta bancaria no tenga saldo negativo aunque durante el procesamiento de la transacción un bean pueda hacerlo temporalmente negativo durante el retiro, pero al completarse la transacción el bean nunca lo deja en negativo.

Demarcaciones de transacción :-

La demarcación de transacción describe quién comienza las transacciones, quién emite un commit o un rollback, y cuándo ocurren cada uno de estos pasos.

Puedes demarcar transacciones EJB de tres formas: 1. Por el cliente 2. Por un EJB 3. Por un cont