Quels sont les caches de premier et deuxième niveau dans Hibernate?
Réponses:
1.1) Cache de premier niveau
Le cache de premier niveau est toujours associé à l' objet Session . Hibernate utilise ce cache par défaut. Ici, il traite une transaction après une autre, ce qui signifie qu'il ne traitera pas une transaction plusieurs fois. Elle réduit principalement le nombre de requêtes SQL dont elle a besoin pour générer une transaction donnée. C'est au lieu de mettre à jour après chaque modification effectuée dans la transaction, il met à jour la transaction uniquement à la fin de la transaction.
1.2) Cache de deuxième niveau
Le cache de second niveau est toujours associé à l' objet Session Factory . Lors de l'exécution des transactions, entre les deux, il charge les objets au niveau de Session Factory, afin que ces objets soient disponibles pour l'ensemble de l'application, et non liés à un seul utilisateur. Étant donné que les objets sont déjà chargés dans le cache, chaque fois qu'un objet est renvoyé par la requête, à ce moment-là, pas besoin d'aller pour une transaction de base de données. De cette façon, le cache de deuxième niveau fonctionne. Ici, nous pouvons également utiliser le cache au niveau des requêtes.
Cité de: http://javabeat.net/introduction-to-hibernate-caching/
Il y a une assez bonne explication de la mise en cache de premier niveau sur le blog Streamline Logic .
Fondamentalement, la mise en cache de premier niveau se produit par session, alors que la mise en cache de deuxième niveau peut être partagée entre plusieurs sessions.
Voici quelques explications de base sur le cache d'hibernation ...
Le cache de premier niveau est associé à l'objet «session». La portée des objets de cache est de session. Une fois la session fermée, les objets mis en cache ont disparu pour toujours. Le cache de premier niveau est activé par défaut et vous ne pouvez pas le désactiver. Lorsque nous interrogeons une entité pour la première fois, elle est récupérée de la base de données et stockée dans le cache de premier niveau associé à la session de mise en veille prolongée. Si nous interrogeons à nouveau le même objet avec le même objet de session, il sera chargé à partir du cache et aucune requête SQL ne sera exécutée. L'entité chargée peut être supprimée de la session à l'aide de la evict()méthode. Le prochain chargement de cette entité fera à nouveau un appel à la base de données si elle a été supprimée à l'aide de la evict()méthode. Le cache de session entier peut être supprimé à l'aide de la clear()méthode. Il supprimera toutes les entités stockées dans le cache.
Le cache de deuxième niveau est distinct du cache de premier niveau qui est disponible pour être utilisé globalement dans la portée de la fabrique de sessions. le cache de deuxième niveau est créé dans la portée de la fabrique de sessions et peut être utilisé dans toutes les sessions créées à l'aide de cette fabrique de sessions particulière. Cela signifie également qu'une fois la fabrique de sessions fermée, tout le cache qui lui est associé meurt et le gestionnaire de cache est également fermé. Chaque fois que la session d'hibernation tente de charger une entité, la toute première place recherche une copie mise en cache de l'entité dans le cache de premier niveau (associée à une session d'hibernation particulière). Si une copie en cache de l'entité est présente dans le cache de premier niveau, elle est renvoyée comme résultat de la méthode de chargement. S'il n'y a pas d'entité mise en cache dans le cache de premier niveau, le cache de deuxième niveau est recherché pour l'entité mise en cache. Si le cache de deuxième niveau a une entité mise en cache, il est renvoyé comme résultat de la méthode de chargement. Mais, avant de renvoyer l'entité, elle est également stockée dans le cache de premier niveau afin que la prochaine méthode d'invocation au chargement de l'entité renvoie l'entité du cache de premier niveau lui-même, et il ne sera pas nécessaire de revenir au cache de deuxième niveau. Si l'entité n'est pas trouvée dans le cache de premier niveau et le cache de deuxième niveau également, la requête de base de données est exécutée et l'entité est stockée dans les deux niveaux de cache, avant de revenir en réponse deload() méthode.
C'est une question très courante, donc cette réponse est basée sur cet article que j'ai écrit sur mon blog.
Cache de premier niveau
Hibernate essaie de différer le contexte de persistance jusqu'au dernier moment possible. Comme je l'ai expliqué dans cet article , cette stratégie est traditionnellement connue sous le nom d'écriture différée transactionnelle.
L'écriture différée est davantage liée au vidage Hibernate qu'à toute transaction logique ou physique. Lors d'une transaction, le vidage peut se produire plusieurs fois.
Les modifications vidées sont visibles uniquement pour la transaction de base de données en cours. Jusqu'à ce que la transaction en cours soit validée, aucune modification n'est visible par les autres transactions simultanées.
En raison du cache de premier niveau, Hibernate peut effectuer plusieurs optimisations:
Cache de deuxième niveau
Une solution de mise en cache appropriée devrait s'étendre sur plusieurs sessions Hibernate et c'est la raison pour laquelle Hibernate prend également en charge un cache de deuxième niveau supplémentaire.
Le cache de deuxième niveau est lié au cycle de vie de SessionFactory, il n'est donc détruit que lorsque le SessionFactoryest fermé (généralement lorsque l'application est en cours de fermeture). Le cache de deuxième niveau est principalement orienté entité, bien qu'il prenne également en charge une solution de mise en cache de requêtes facultative.
Pour plus de détails, consultez cet article .
par défaut, NHibernate utilise la mise en cache de premier niveau qui est basée sur les objets de session. mais si vous exécutez dans un environnement multi-serveur, le cache de premier niveau peut ne pas être très évolutif avec certains problèmes de performances. cela se produit en raison du fait qu'il doit effectuer des déplacements très fréquents dans la base de données car les données sont réparties sur plusieurs serveurs. en d'autres termes, NHibernate fournit un cache L1 en cours de traitement de base, pas si sophistiqué. Cependant, il ne fournit pas les fonctionnalités qu'une solution de mise en cache doit avoir pour avoir un impact notable sur les performances de l'application.
la question de tous ces problèmes est donc l'utilisation d'un cache L2 qui est associé aux objets de fabrique de session. il réduit les trajets fastidieux vers la base de données et augmente ainsi le temps de réponse de l'application.
Cache de premier niveau
L'objet session contient les données de cache de premier niveau. Il est activé par défaut. Les données de cache de premier niveau ne seront pas disponibles pour l'ensemble de l'application. Une application peut utiliser plusieurs objets de session.
Cache de deuxième niveau
L'objet SessionFactory contient les données de cache de deuxième niveau. Les données stockées dans le cache de deuxième niveau seront disponibles pour toute l'application. Mais nous devons l'activer explicitement.
Dans un cache de deuxième niveau, les fichiers hbm de domaine peuvent être de clé mutable et de valeur false. Par exemple, dans cette classe de domaine, une partie de la durée d'une journée reste constante en tant que vérité universelle. Ainsi, il peut être marqué comme immuable dans toute l'application.