Supongo que se está ejecutando en SQL Server (debido a la etiqueta), de lo contrario, mi respuesta no es aplicable. El bloqueo solo no es suficiente. Si utiliza el bloqueo de registros de la base de datos, el servidor SqL bloqueará otros procesos que intenten acceder a la fila bloqueada y, de hecho, manejará solo una fila a la vez. La solución para usted es combinar el bloqueo de filas con la sugerencia de READPAST para que las filas bloqueadas por alguien más se omitan. Esto es lo que cada proceso debe hacer:
- seleccione siguiente fila desbloqueado para su procesamiento y bloquearla
- haga el trabajo
- actualización de la transacción fila y al final
select top 1 id, ... from TheTable with (updlock, readpast) where flag = 0
//do the work now
update TheTable set flag = 1 where id=<previously retrieved id>
Lo bueno aquí es que la operación de seleccionar la siguiente fila desbloqueada y bloquearla es atómica, por lo que garantiza que nadie más podrá seleccionar la misma fila.
LECTURA DE READPAST hace el truco, un buen artículo http://www.mssqltips.com/sqlservertip/1257/processing-data-queues-in-sql-server-with-readpast-and-updlock/ – newbie
Con SQL 2008 , puede usar la cláusula OUTPUT con la sugerencia de LECTURA en la consulta para combinar la operación de cola en una sola instrucción.http: //www.sqlservercentral.com/articles/Queue+processing/69653/ – newbie
@newbie Sí, puede usar salida para bloquear y recuperar mensajes y marcarlos procesados en una sola consulta. Pero he estado comparando el rendimiento para el procesamiento de mensajes únicos y no hay ganancia en comparación con dos consultas (seleccione primero y luego actualice). En realidad, el rendimiento de subprocesos múltiples fue un poco menor cuando se usaba la consulta SALIDA. Tal vez en el procesamiento por lotes la cláusula de salida sea más rápida, pero para los mensajes individuales no lo es. – nightwatch