En bref :
- Utilisez toujours les transactions
- N'utilisez pas
Close() au lieu d'envelopper vos appels dans un ISession à l'intérieur d'un using déclaration ou gérer le cycle de vie de votre session IS ailleurs .
De la documentation :
De temps en temps, le ISession exécutera les instructions SQL nécessaires pour synchroniser l'état de la connexion ADO.NET avec l'état des objets conservés en mémoire. Ce processus, la chasse d'eau, se produit par défaut aux points suivants
- de certaines invocations de
Find() ou Enumerable()
- de
NHibernate.ITransaction.Commit()
- de
ISession.Flush()
Les instructions SQL sont émises dans l'ordre suivant
- toutes les insertions d'entités, dans le même ordre que les objets correspondants ont été sauvegardés à l'aide de la fonction
ISession.Save()
- toutes les mises à jour des entités
- toutes les suppressions de collections
- toutes les suppressions, mises à jour et insertions d'éléments de la collection
- toutes les insertions de collections
- toutes les suppressions d'entités, dans le même ordre que celui dans lequel les objets correspondants ont été supprimés à l'aide de la fonction
ISession.Delete()
(A l'exception des objets utilisant la génération native d'ID qui sont insérés lors de leur sauvegarde).
Sauf quand vous êtes explicitement Flush() Il n'y a absolument aucune garantie quant au moment où la session exécute les appels ADO.NET, mais seulement quant à l'ordre dans lequel ils sont exécutés. . Cependant, NHibernate garantit que le fichier ISession.Find(..) ne renverront jamais des données périmées, ni des données erronées.
Il est possible de modifier le comportement par défaut de manière à ce que la purge soit moins fréquente. Le site FlushMode définit trois modes différents : uniquement la purge au moment de la livraison (et uniquement lorsque la classe NHibernate ITransaction est utilisée), effectuer un vidage automatique à l'aide de la routine expliquée, ou ne jamais effectuer de vidage à moins que l'API Flush() est appelé explicitement. Le dernier mode est utile pour les unités de travail de longue durée, où une unité de travail de type ISession est maintenu ouvert et déconnecté pendant une longue période.
...
Voir également cet article :
La fin d'une session comporte quatre phases distinctes :
- purger la session
- valider la transaction
- clôturer la session
- gérer les exceptions
Vider la session
Si vous utilisez le ITransaction API, vous n'avez pas besoin de vous soucier de cette étape. Elle sera exécutée implicitement lorsque la transaction sera validée. Sinon, vous devez appeler ISession.Flush() pour s'assurer que toutes les modifications sont synchronisées avec la base de données.
Validation de la transaction de la base de données
Si vous utilisez l'API NHibernate ITransaction, cela ressemble à ceci :
tx.Commit(); // flush the session and commit the transaction
Si vous gérez vous-même les transactions ADO.NET, vous devez manuellement Commit() la transaction ADO.NET.
sess.Flush();
currentTransaction.Commit();
Si vous décidez de ne pas valider vos modifications :
tx.Rollback(); // rollback the transaction
ou :
currentTransaction.Rollback();
Si vous annulez la transaction, vous devez immédiatement fermer et abandonner la session en cours afin de garantir la cohérence de l'état interne de NHibernate.
Fermeture de la session IS
Un appel à ISession.Close() marque la fin d'une session. La principale implication de Close() est que la connexion ADO.NET sera abandonnée par la session.
tx.Commit();
sess.Close();
sess.Flush();
currentTransaction.Commit();
sess.Close();
Si vous avez fourni votre propre connexion, Close() renvoie une référence à celui-ci, afin que vous puissiez le fermer manuellement ou le remettre dans le pool. Sinon, Close() le renvoie dans la piscine.
