Non. Les verrous ne sont placés que pour l'étendue d'une transaction, qui, dans une application Web, se termine lorsque la demande se termine. En outre, le type par défaut du mode d'isolation des transactions est Read commited ce qui signifie que les verrous en lecture sont libérés dès que l'instruction select se termine. Si vous lisez et apportez des modifications dans la même demande et la même transaction, vous pouvez placer un verrou de lecture et d'écriture sur la ligne en cours, ce qui empêchera d'autres transactions d'écrire ou de lire à partir de cette ligne. Cependant, ce type de contrôle de la concurrence ne fonctionne pas bien dans une application Web.
Cela se produirait si la [concurrence optimiste] était utilisée. Dans NHibernate, la concurrence optimiste fonctionne en ajoutant un champ version . Les commandes de sauvegarde/mise à jour sont émises avec la version sur laquelle la mise à jour était basée. Si cela diffère de la version dans la table de la base de données, aucune ligne n'est mise à jour et NHibernate lancera.
Non, le verrou est relâché à la fin de la requête.
Dans l'ensemble, votre meilleur pari est d'opter pour une concurrence optimiste avec des champs de version gérés par NHibernate.
