Bloquear para manejar concurrencia-- una buena idea?

Question

Para manejar el problema de simultaneidad, ¿está bloqueando-- cualquier forma de bloqueo, ya sea que la fila, la tabla o la base de datos bloqueen una buena solución?

Si no, ¿cómo manejar el problema de simultaneidad?

Answer 1

Si cree en Oracle, no, en absoluto. Eso es porque Oracle hizo todo lo posible para evitarlo.

El problema es que los lectores pueden bloquear a escritores y escritores bloquean lectores, y un escritor tiene que esperar hasta que todos los lectores hayan terminado con una fila antes de poder escribir. Eso retrasa el proceso de escritura y su llamador. Los bloqueos exclusivos (para escritura) se retienen hasta el final de la transacción, en caso de que la transacción deba revertirse; esto detiene otras transacciones que ven el nuevo valor hasta que la transacción se compromete.

En la práctica, el bloqueo generalmente es correcto si no hay demasiada contención, al igual que con cualquier programación simultánea. Si hay demasiada contención para una fila/página/tabla (no muchos servidores de bases de datos bloquean la base de datos completa), las transacciones se ejecutarán una por una en lugar de concurrentemente.

Oracle utiliza versiones de filas, donde en lugar de bloquear una fila para escribirla, se crea una nueva versión de la fila.Los lectores que necesitan repetir sus lecturas recuerdan qué versión de la fila leen. Sin embargo, se producirá un error si un lector que está recordando sus lecturas intenta actualizar una fila que ha sido actualizada por otro escritor desde que esta transacción la leyó; esto es para detener las actualizaciones perdidas. Para asegurarse de que puede actualizar una fila, debe decir que SELECCIONAR está PARA ACTUALIZAR; si lo hace, se necesita un bloqueo: solo una transacción puede contener una fila PARA ACTUALIZAR a la vez, y una transacción en conflicto tiene que esperar.

SQL Server 2005 y posterior son compatibles con el aislamiento de instantáneas, que es su nombre para las versiones de filas. De nuevo, debe solicitar bloqueos de actualización si necesita actualizar algunos datos que acaba de leer: en SQL Server, use WITH (UPDLOCK).

Otro problema con el bloqueo es la probabilidad de interbloqueos. Esto es simplemente cuando dos transacciones mantienen un bloqueo en un recurso que el otro necesita, o en general un ciclo de transacciones mantiene bloqueos que el otro necesita para progresar. El servidor de la base de datos generalmente detectará este interbloqueo y eliminará una de las transacciones y la retrotraerá; luego deberá volver a intentar la operación. Cualquier situación en la que tenga múltiples transacciones simultáneas modificando las mismas filas tiene potencial para un punto muerto. El punto muerto se producirá si las filas se tocan en un orden diferente; es muy difícil hacer cumplir el orden que usará el servidor de la base de datos (en general, usted quiere que el optimizador elija el orden más rápido, lo que no necesariamente será uniforme en las diferentes consultas).

En general, sugeriría lo mismo que con el enhebrado: vaya con bloqueos hasta que pueda probar que están causando un problema de escalabilidad, y luego descubra cómo hacer que las secciones más críticas estén libres de bloqueos.

Answer 2

Creo que no, porque está todo el camino "abajo" y hace que su aplicación sea más compleja. La mayoría de los lenguajes tienen excelentes técnicas de manejo de concurrencia, e incluso entonces la mejor manera es escribir un código que pueda manejar la concurrencia "de forma nativa".

Para obtener más información sobre la concurrencia en Java: http://java.sun.com/docs/books/tutorial/essential/concurrency/index.html

Answer 3

¿Quieres decir para manejar la concurrencia en su aplicación, o para resolver un problema de concurrencia que tiene con la base de datos. Si lo primero, no me parece un buen enfoque. Si es este último, esta puede ser su única respuesta sin rediseñar sus esquemas.

Answer 4

El bloqueo de la base de datos, a diferencia del bloqueo de tabla o fila, es una mala forma de manejar la concurrencia; descarta la concurrencia.

Answer 5

Primero tiene que definir su objetivo. En caso de solicitud simultánea, ¿le gustaría ganar el último usuario o el primer usuario? El bloqueo de la base de datos es una mala forma. Intente bloquear la tabla/filas lo más tarde posible y suelte el bloqueo lo antes posible.

Answer 6

Hay muchas alternativas razonables a tener que codificar el bloqueo de DMBS de algún tipo usted mismo. Tenga en cuenta que siempre está ocurriendo algún tipo de bloqueo (acciones atómicas, etc.) pero la clave es que no quiere ir allí si no es necesario. No quieres cenar con filósofos si no tienes que hacerlo. Las transacciones son una forma de evitar el bloqueo, pero eso es principalmente para commits. Usando un campo que marca/indica que el registro está sucio, el (patrón de bits sucios) es de otra manera, solo asegúrate de hacerlo de manera atómica. El lenguaje a menudo tiene una solución adecuada como se menciona en publicaciones anteriores, sin embargo, el lenguaje normalmente solo admite aplicaciones, proceso a proceso, nivel de concurrencia y, a veces, la concurrencia tiene que ser en la base de datos. No quería suponer que tiene una capa de aplicaciones enriquecida, pero si lo hace, hay muchas capas abstractas que manejan esto por usted. TopLink by Oracle es gratuito y es el hermano más robusto de Hibernate, que le ayuda a administrar los desafíos de concurrencia de su base de datos a través de abstracción, bits sucios, almacenamiento en caché y bloqueo lento. Realmente no desea implementarlos usted mismo, a menos que esté codificando para un proyecto escolar o personal. Comprenda el problema, pero párese sobre los hombros de los gigantes.