Problema de concurrencia de inserción - Entorno multiproceso

Question

Tengo un problema con que se invoque el mismo procedimiento almacenado exactamente al mismo tiempo con exactamente los mismos parámetros.

El objetivo del procedimiento almacenado es recuperar un registro si existe o crear y recuperar el registro si no existe.

El problema es que ambos hilos están comprobando la existencia del registro y el informe falso y luego ambos están insertando un nuevo registro, creando un duplicado en la base de datos.

Intenté pegar las operaciones dentro de una transacción pero esto simplemente produjo cientos de puntos muertos.

¿Hay alguna forma de que pueda verificar la existencia del registro de forma segura para que el segundo hilo no lo lea hasta que el primero haya terminado su inserción? No tengo control sobre los hilos, solo sobre los procesos almacenados que están ejecutando.

Cualquier ayuda sería apreciada,

Gracias.

Answer 1

Problema al hacer una selección y luego insertar, normalmente hay un bloqueo de lectura para la selección y luego un bloqueo de escritura en la inserción. Sin una transacción, el tiempo de muchas actualizaciones a menudo permitirá que ocurran múltiples insertos, como puede ver. En una transacción, el primer bloqueo de lectura detendrá que otros procesos obtengan un bloqueo de escritura y, si más de un proceso obtiene un bloqueo de lectura, ninguno puede obtener un bloqueo de escritura y se produce un interbloqueo.

En este caso, modificaría el código de inserción para que los índices solo permitan que una inserción funcione, es decir, usted tiene una clave única y solo un proceso no podrá insertar los datos para no obtener duplicados. El proceso de actualización se encuentra entonces en una transacción ya sea

1) hacer la pieza de inserción primera y tratar con una excepción o error si se intenta insertar un duplicado

o 2) hacer un LOCK espera (Sybase y SQL Server) al hacer la selección primero - por lo tanto, el primero en bloquear obtiene el permiso completo para insertarlo si es necesario

o 3) Posiblemente utilice el comando de combinación si el RDBMS lo permite. Esto realiza la comprobación e inserta todo en un comando, pero siempre cambiará la base de datos.

EDIT: Creo que no existe una alternativa real a 1 si necesita asegurarse de que haya un solo registro insertado como prueba para eso en una transacción.

el costo se puede reducir verificando la existencia forst en una transacción y luego haciendo la inserción y marcando otra transacción. Por lo tanto, en la mayoría de los casos, solo tiene un seleccionar y en los otros casos, obtiene la inserción y comprobación lentas completas, pero esto debería ocurrir con menos frecuencia.

Answer 2

No estoy seguro de si SQL Server lo tiene. Pero en MySQL y en Oracle puedes obtener el bloqueo de escritura mientras haces una selección usando para actualizar la sintaxis.

select * 
from table 
for update 

Dado que otros hilos también necesitan bloqueo de escritura mientras seleccionan, esperarán hasta que el primer hilo complete la transacción.

Answer 3

El truco consiste en agregar un DONDE a su instrucción INSERT para que INSERT solo funcione si el elemento no existe, seguido de la instrucción SELECT. Suponiendo que el registro puede ser identificado por una columna de ID que iba a escribir:

INSERT INTO MyTable (ID,Col1,Col2,...) 
SELECT @IDValue,@Col1Value,@Col2Value, ... 
WHERE NOT EXISTS (SELECT ID 
       FROM MyTable 
       WHERE ID=@IDValue) 

SELECT * 
FROM MyTable 
Where ID=@IDValue 

No es necesario poner las declaraciones en una transacción debido a que cada sentencia se ejecuta en su propia transacción implícita. Por lo tanto, no hay forma de que dos INSERTOS tengan éxito al mismo tiempo.

EDIT: La sintaxis INSERT ... SELECT es necesaria porque TSQL no permite una parte VALUES y una parte WHERE en la instrucción INSERT.

Answer 4

Supongo que está utilizando C# para comunicarse con el servidor sql, entonces puede intentar consultar el paralelismo de tareas y la biblioteca de tareas para realizar múltiples subprocesos en los procedimientos almacenados.