No. Los bloqueos solo se colocan por el alcance de una transacción, que en una aplicación web finaliza cuando finaliza la solicitud. Además, el tipo predeterminado de modo de aislamiento de transacciones es Lectura confirmada lo que significa que los bloqueos de lectura se liberan tan pronto como finaliza la declaración de selección. Si está leyendo y editando la misma solicitud y transacción, puede colocar un bloqueo de lectura y escritura en la fila en cuestión, lo que evitaría que otras transacciones escriban o lean en esa fila. Sin embargo, este tipo de control de concurrencia no funciona bien en una aplicación web.
Esto sucedería si se estuviera utilizando [simultaneidad optimista]. En NHibernate, la concurrencia optimista funciona agregando un campo de versión . Los comandos de guardar/actualizar se emiten con la versión en la que se basó la actualización. Si eso difiere de la versión en la tabla de la base de datos, no se actualizan filas y NHibernate arrojará.
No, el bloqueo se libera al final de la solicitud.
En general, su mejor apuesta es optar por la concurrencia optimista con campos de versión administrados por NHibernate.
