Est-il prudent d'utiliser un sp_getapplock SQL Server appartenant à une session avec EF6 DbContexts?

Je m'interroge sur les risques / la security de l'utilisation d'un context EF avec sp_getapplock et le type de propriétaire de session. D'après les docs , je crois comprendre qu'un propriétaire de session veut dire que le verrou sera libéré lorsque la session se terminera, s'il n'est pas explicitement publié avant cela. Je suppose que cela signifie également que la connection se termine.

Tout cela fonctionne déjà avec des verrous appartenant à des transactions, mais cela entraîne d'autres problèmes et complications, alors je me pose des questions sur les verrous appartenant à des sessions et sur la manière dont cela va ou non entrer en DbContext avec le comportement de DbContext et ses gestion des connections.

Je ne suis pas sûr à 100% comment DbContext fonctionne par défaut, qu'il utilise un pool ou que chaque instance de context ouvre et ferme ses propres connections (les documents que j'ai lus semblent suggérer le dernier). Pour cette question, supposons que je ne fais rien avec la gestion des connections (ce que je fais rarement), donc EF gère cela, ou tout ce qui gère la gestion.

Si je crée une instance DbContext , saisis la connection, exécute SQL pour créer un verrou appartenant à une session , utilise le context comme d'habitude, ne libère pas le verrou et ne dispose pas du context, cela fonctionnera-t-il correctement? (En réalité, ce serait dans un emballage IDisposable pour empêcher cela, mais la question demeure.)

• Ajouter un élément à la queue Azure Service Bus lorsqu'un logging de table de database spécifique est inséré / mis à jour / supprimé
• Comment puis-je download une database locale vers Windows Azure?
• Jointure interne SQL complexe et champ conditionnel à LINQ. (Mon LINQ produit des duplicates.)
• Emprunter l'identité de l'user Windows au server SQL
• Lire l'object OLE avec C #

Pour illustrer mal:

 using (var ctx = new MyContext()) { var conn = ctx.Database.Connection.Open(); conn.ExecuteSqlSomehow("sp_getapplock blahblah"); try { // Lots of queries, savechanges, etc. } finally { // Oops I forgot to conn.ExecuteSql("sp_release the lock"); } } await WatchMovieAsync(); using (var ctx = new MyContext()) { // Can this reuse the same connection, session and/or lock? } 

Des questions:

1. Un autre context pourrait-il en quelque sorte réutiliser ma connection et son verrou de session après avoir disposé de l'instance?
2. D'ailleurs, un autre context (par exemple dans un autre thread) pourrait-il utiliser une connection sur laquelle j'ai émis le verrou alors que le thread original est toujours dans le bloc using ?
3. EF peut-il fermer la connection verrouillée et en ouvrir une autre ultérieurement dans le même bloc (par exemple pour SaveChanges ), libérant ainsi le verrou?

• Existe-t-il un moyen d'améliorer les performances lors de l'envoi d'un grand nombre d'ID au server SQL pour le filtrage?
• Meilleure pratique pour développer la database de gestion WCF pour plusieurs users
• Comment vérifier le text de combobox avec la valeur de la colonne de database
• SSIS: Impossible de convertir un object de type 'System.Decimal' en type 'System.Char '
• Comment connecter la database SQL Server Express à VS 2017