El control de accesos concurrentes y específicamente de transacciones concurrentes es manejado por un módulo del dbms llamado "scheduler".
Es importante recordar que muchos de los datos de la base no se encuentran nada más en disco, sino tambien en los buffers de memoria, de ahí que el scheduler interactúa con ellos y en su defecto solicita la lectura de los datos del disco.
Ejemplo en el que podemos observar la incidencia del control de concurrencia en el siguiente: en una Base de Datos bancaria podría ocurrir que se paguen dos cheques en forma simultánea sobre una cuenta que no tiene saldo suficiente para cubrirlos en su totalidad, esto es posible evitarlo si se tiene un control de concurrencia.
Todos los mecanismos de control de concurrencia deben asegurar la consistencia de los objetos y cada transacción atómica será completada en un tiempo finito. Un método de control de concurrencia es correcto si es serializable, es decir existe una secuencia equivalente en que las operaciones de cada transacción aparecen antes o después de otra transacción pero no entremezcladas. Una ejecución serial de transacciones es siempre correcta.
Se debe sincronizar las transacciones concurrentes de los usuarios, extendiendo los argumentos para la serializabilidad y los algoritmos de control de concurrencia para la ejecución en ambientes distribuidos. La finalidad del control de concurrencia es asegurar la consistencia de los datos al ejecutar transacciones, y que cada acción atómica sea completada en un tiempo finito.
Uno de los problemas de concurrencia específicos de las bases de datos distribuidas es la consistencia de copia múltiple (se produce cuando un mismo dato esta en varias localizaciones). Además se siguen dando los mismos problemas para bases de datos centralizadas (pérdida de actualizaciones, dependencia neutral (uncommitted dependency) y análisis inconsistentes).