Las consultas que se ejecutan en forma simultánea son precisamente el corazón del problema de la administración de base de datos distribuidas y en red. Es justamente allí donde nace la necesidad de las transacciones, que permiten el desarrollo de consultas multithread.
No es un tema que se pueda responder en un post. Se trata de algo que implica MUCHO análisis, MUCHO diseño, MUCHA programación y otros muchos más. Hay tratados completos sobre el tema.
Para decirlo brevemente, la existencia de transacciones concurrentes es algo que se debe considerar siempre que se desarrolla una base de datos que se accederá por más de un usuario simultáneamente. Para ello existen sentencias y comandos, tanto a nivel de la base de datos, como al nivel de la aplicación, que permite que los threads de las consultas se ejecuten en una secuencia que no genere inconsistencias y problemas de integridad.
A nivel de las transacciones, debe diseñarse cada consulta y cada procedimiento para que ciertos pasos se consideren atómicos (indivisibles) y si se aborta una sola fase del proceso, se aborte totalmente la transacción. Este tipo de acciones está definida por el concepto de ACID (Atomicity, Consistency, Isolation and Durability) y se implementa de formas bastante complejas.
Un ejemplo del uso de las transacciones concurrentes lo tienes frente a tí casi a diario: Los cajeros automáticos de los bancos. Funcionan bajo ese principio. Si quieres acceder, por ejemplo, en dos cajeros con dos tarjetas a la misma cuenta, puedes hacerlo, pero retirar dinero, solamente podrá hacerlo uno a la vez de la misma cuenta, y si después de ver el saldo de la cuenta, quisieras retirar todo el monto que te indicó de saldo, pero el otro cajero retira una parte, entonces tu no podrás retirar ese monto mostrado, porque entre que tu consultaste el saldo y que pediste el retiro, el otro cajero debitó x dinero de la misma cuenta, y por tanto el saldo es insuficiente.
Todo eso se controla con diferentes niveles de bloqueo. En algunas ocasiones se bloquea la lectura pero no la escritura (miras el saldo, pero no retiras aún), en otras se bloquea todo (consolidación de la cuenta), en otras la escritura, pero no la lectura (consultas pero no retiras).
¿Se entiende?
Este tipo de diseño puede implicar:
- Bloqueos a nivel de base.
- Bloqueos a nivel de tablas.
- Bloqueos a nivel de registro
- bloqueos a nivel de campo.
También puede implicar diseñar un conjunto de permisos aplicables a usuarios categorizados, crear roles de usuarios y de grupos, etc. Por caso, cuando en una empresa se registra un usuario, según el área de trabajo se le asigna un rol que contiene permisos predefinidos. Esto se hace para evitar tener que darle permisos manualmente, con lo que pueden cometerse errores.
En las .Net pueden controlarse directamente en la aplicación. En otros lenguajes es posible que se tenga que realizar mediante procedimientos almacenados.
Acá vas a encontrar más sobre el tema:
Transacciones y operaciones atómicas