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.
código que puede manejar concurrencia "nativamente" ... ¿alguna sugerencia sobre cómo? – Graviton
Creo que quiere decir usar las características del lenguaje de programación o la biblioteca, como java.util.concurrent. –
Sí. También vea http://java.sun.com/docs/books/tutorial/essential/concurrency/index.html – Rolf