database - sirven - niveles de aislamiento de transacciones en sql server

Nivel de aislamiento vs bloqueo optimista Hibernate, JPA

Question

Tengo una aplicación web en la que deseo asegurar la concurrencia con un bloqueo de nivel de base de datos en el objeto que intento actualizar. Quiero asegurarme de que un cambio de lote u otro usuario o proceso no termine introduciendo incoherencias en el DB.

Veo que los niveles de aislamiento garantizan la coherencia de lectura y el bloqueo optimista con el campo @Version puede garantizar que los datos @Version escritos con un estado coherente.

Mi pregunta es: ¿no podemos garantizar la coherencia solo con el nivel de aislamiento? Al realizar cualquier transacción que actualice el registro Serializable (sin considerar el rendimiento), ¿no me aseguraré de que la transacción y cualquier otra transacción que intente actualizar o adquirir el bloqueo genere un bloqueo adecuado o fallará esta transacción? ¿Realmente necesito la administración de la versión o de la marca de tiempo para esto?

Answer 1

A menos que hablemos de una aplicación web pequeña y aislada (solo la aplicación que está trabajando en una base de datos), hacer que todas sus transacciones sean Serializables significaría tener mucha confianza en su diseño, sin tomar en cuenta el hecho de que puede no ser la única aplicación que golpea en esa cierta base de datos.

En mi opinión, la incorporación de un nivel de aislamiento serializable, o un bloqueo pesimista en otras palabras, debería ser una decisión muy bien tomada y aplicada para:

• Grandes bases de datos y transacciones cortas que actualizan solo unas pocas filas
• Donde la posibilidad de que dos transacciones simultáneas modifiquen las mismas filas es relativamente baja.
• Donde las transacciones de larga duración son principalmente de solo lectura.

De acuerdo con mi experiencia, en la mayoría de los casos el uso de Optimistic Locking sería la decisión más beneficiosa, ya que las modificaciones simultáneas frecuentes ocurren principalmente en un pequeño porcentaje de casos. El bloqueo optimista también ayuda a otras aplicaciones a funcionar más rápido (¡no piense solo en usted mismo!).

Entonces, cuando tomamos el espectro de estrategias de bloqueo pesimista y optimista, en mi opinión, la verdad está en algún lugar más hacia el bloqueo optimista con un sabor de serializable aquí y allá.

Realmente no puedo hacer referencia a nada aquí, ya que la respuesta se basa en mi experiencia personal con muchos proyectos web complejos y en mis notas cuando estaba listo para mi Certificado JPA.

Espero que ayude.

Answer 2

Dependiendo del nivel de aislamiento que haya elegido, el recurso específico se bloqueará hasta que la transacción se confirme o se retrotraiga: puede bloquearse en una tabla, fila o bloque enteros de sql. Es un bloqueo pesimista y está garantizado en el nivel de la base de datos cuando se ejecuta una transacción.

Por otra parte, el bloqueo optimista supone que las transacciones múltiples raramente interfieren entre sí, por lo que no se requieren bloqueos en este enfoque. Se trata de una verificación del lado de la aplicación que utiliza el atributo @Version para establecer si la versión de un registro ha cambiado entre la búsqueda y el intento de actualizarla.

Es razonable utilizar un enfoque de bloqueo optimista en las aplicaciones web, ya que la mayoría de las operaciones abarcan varias solicitudes HTTP. Por lo general, obtiene información de la base de datos en una solicitud y la actualiza en otra. Sería muy costoso e imprudente mantener las transacciones abiertas con un bloqueo de recursos de bases de datos tan largo. Es por eso que suponemos que nadie va a utilizar el conjunto de datos en el que estamos trabajando, es más barato. Si la suposición es incorrecta y la versión ha cambiado entre las solicitudes de otra persona, Hibernate no actualizará la fila y lanzará OptimisticLockingException . Como desarrollador, usted es responsable de gestionar esta situación.

Ejemplo simple Servicio de subastas en línea: está viendo una página de artículo. Usted lee su descripción y especificación. Todo lleva, digamos, 5 minutos. Con el bloqueo pesimista y algunos niveles de aislamiento bloquearía a otros usuarios de esta página de elementos en particular (¡o incluso a todos los elementos!). Con un bloqueo optimista, todos pueden acceder a él. Después de leer sobre el artículo que está dispuesto a ofertar, haga clic en el botón adecuado. Si cualquier otro usuario que mira este elemento y cambia su estado (el propietario cambió su descripción, alguien más puje por él) mientras tanto probablemente (dependiendo de la implementación de la aplicación) se le informará sobre los cambios antes de que la aplicación acepte su oferta porque la versión Tengo no es lo mismo que la versión persistió en la base de datos.

Espero que aclare algunas cosas para ti.