LINQ to SQL and Concurrency Issues

Question

Estamos tratando de crear un sistema de registro de pedidos de gran volumen. Hay tres tablas principales: 1. Las órdenes de 2. OrderDetails 3. OrderShipment

La tabla de envío contiene el registro n por pedido y cualquier entrada de registro de embarque pueden ser cambiados antes de que el cliente acepta º orden, después de lo cual es congelado. (Requisito empresarial)

Aunque esto no ocurra en los escenarios del mundo real ... durante nuestras pruebas de carga, obtenemos excepciones de System.Data.Linq.ChangeConflictException. Cerrar el envío dentro de una transacción tampoco está ayudando. ¿No podemos forzar a LINQ a obtener un bloqueo en la fila durante toda la operación de actualización?

¿Hay alguna otra forma de superar esto?

Answer 1

Si tiene problemas reales con las actualizaciones simultáneas en los mismos datos, entonces podría considerar realizar toda la operación en una transacción, es decir, obtener los datos y comprometiéndolo. Siempre que trate el get/update/commit como una operación atómica de vida corta (es decir, no hace una pausa para la entrada del usuario en el medio), debería estar bien.

En particular, con un nivel de aislamiento serializable, nadie puede actualizar los datos que usted tiene un bloqueo de lectura en (es decir, todo lo que han buscado). El único problema es que esto podría conducir a escenarios de interbloqueo si las diferentes consultas están leyendo datos en diferentes órdenes. AFAIK, no hay forma de que LINQ-to-SQL emita la sugerencia (UPDLOCK), lo cual es una lástima.

Ya sea un TransactionScope o una SqlTransaction haría, siempre y cuando se establecen aislamiento como serializable (que es el valor predeterminado para TransactionScope).

Answer 2

es posible que desee ver en Entity Framework que ejecuta todo como una transacción. Aquí hay dos podcasts que también pueden ser interesantes sobre Entity Framework.

DNRTV - part 1 - part 2

Answer 3

Para este tipo de situaciones, es decir, que más de un usuario puede querer realizar cambios en el mismo registro/cliente/pedido/lo que sea mejor para construir "bloqueo" en la lógica de la aplicación en lugar de utilizar los bloqueos de la base de datos.

el uso de bloqueos de base de datos para resolver bloqueo lógica de los datos que se va a presentar con un montón de nuevos problemas. Una mejor solución es tener columnas y/o tablas en las que pueda indicar que un usuario/cliente está editando una orden/un cliente, hasta que esté bloqueado, etc. Consulte esa tabla (o columnas) para verificar si el cliente/order/thing está disponible para editar antes de permitir que otro usuario lo edite.

Ver: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3984968&SiteID=1