Marco Transaccional
Una operación se puede pensar como una transición entre dos estados. Entre estos dos estados existen estados intermedios, internos a la construcción, del cual no se toma conocimiento hasta que la entidad es finalmente construida. La función de la aplicación es guiar al usuario en esta construcción, con suficiente información acerca del estado actual, restringiendo los caminos hacia inconsistencias pero flexibilizando para no entorpecer la capacidad constructiva. Esta construcción toma la forma de una transacción de negocio.
Requisitos
Una transacción de negocio tiene impuesta generalmente distintos requisitos: los efectos de la misma no serán conocidos en forma parcial (atomicidad), ni rompen las reglas preestablecidas (consistencia), su desarrollo se basa sobre datos certeros y su resultado no es conocido hasta su finalización (aislamiento), finalmente estos resultados perduran en el tiempo (durabilidad). Estos requisitos se conocen como ACID en base a las siglas de cada uno.
Las bases de datos relacionales, en mayor o menor medida, poseen mecanismos para garantizar estos requisitos simplemente incluyendo la operación dentro de una transacción de base de datos.
Hay algunos problemas con esta solución, el primero es la llamada disponibilidad de los datos. Para asegurar la consistencia en general se utilizan bloqueos pesimistas, previniendo que los recursos sean utilizados por otros mientras la transacción está en curso, en una aplicación Web una transacción de negocios puede durar varios minutos, incluso por su naturaleza desconectada, varias horas. Bloquear registros por horas puede traer problemas graves de concurrencia, dejando ramas de operaciones inaplicables por causa del bloqueo. Es por esto que se construyen técnicas a un nivel superior utilizando los llamados bloqueos optimistas, relegando los bloqueos a nivel de base de datos hasta el final de la transacción de negocio y sólo aplicando restricciones a los datos que tienen valor real de negocio. Por ejemplo en los carritos de compras de ventas online, si hay disponible una única unidad de un producto no se previene que dos usuarios lo agreguen simultáneamente a su carrito, dejan los controles hasta el final de la transacción cuando el usuario confirma la adquisición, de lo contrario se pierde un potencial cliente en base a una suposición incorrecta (un alto porcentaje no hace un checkout de la elección).
Aún cuando los motores brinden capacidad de bloqueos optimistas, desde el lenguaje de programación (en este caso PHP) se debería mantener abierta una conexión con la base por cada sesión en curso (si cerrara la conexión cuando termina el pedido de página automáticamente se abortaría la transacción). Esto actualmente no es técnicamente posible, y si lo fuera sería tremendamente ineficiente para un sistema con mucha carga.
Operación
Una operación definida en toba traspasa por tres estados principales: un inicio, un desarrollo y un procesamiento final. El progreso se da a manera de turnos entre el lado cliente y el servidor, representados por el navegador y PHP respectivamente. Dentro de una operación existen datos transaccionales y otros ordinarios, que no requieren las calidades vistas anteriormente. Estos datos ordinarios serán consultados en cada pedido de página, mientras que los transaccionales serán consultados al inicio de la operación, modificados durante el desarrollo (en forma de variables de sesión) y finalmente sincronizados con la fuente de datos al final de la operación a través de una transacción de base de datos.
Pedido de página
El control general de un pedido de página está a cargo de los Controladores de interface. Al inicio del pedido se restaura el estado del CI, este estado se persiste entre pedidos utilizando las variables de sesión de PHP, garantizando el aislamiento entre las distintas operaciones en ejecución. Por otro lado, desde los elementos de interface (ei) se reciben los eventos (datos proporcionados por el usuario). Estos eventos se escuchan en código recibiendo los datos como parámetro, allí es cuando se realizan chequeos y se cambia el estado interno de la operación. Hay operaciones que por su complejidad requieren un número importante de Controladores de interface, entonces lo que se hace es centralizar la información en un Controladores de negocio.
Luego del procesamiento de eventos provenientes del pedido anterior, el ítem se prepara para brindar el servicio requerido, generalmente lanzando la construcción de la salida HTML. Finalmente el estado de CIs,CNs y componentes de persistencia vuelve a almacenarse en variables de sesión, listo para continuar el ciclo.
Cuando la información que se maneja en esta transacción de negocios es un conjunto de datos tabulares cuya carga y sincronización es con una base de datos relacional existen una serie de componentes que facilitan:
- La carga de los datos.
- El trabajo dentro de la transacción.
- La sincronización con el medio de persistencia.
Se los conoce como Componentes de Persistencia
El ciclo finaliza con un evento (generalmente nombrado como procesar) localizado en el CI de la operación. Este evento es el encargado de sincronizar con la fuente de datos utilizando una transacción de base de datos que garantiza la atomicidad y durabilidad de la operación. Este evento es un lugar adecuado para realizar los controles finales sobre los datos obtenidos, garantizando así la consistencia de los mismos.
Ejemplo
Por ejemplo si se tratara de una operación que recolectara direcciones de mail para posteriormente mostrando una grilla con las direcciones para ser enviadas, el gráfico anterior estaría instanciado de la siguiente manera:
