Quels sont les caches de premier et de second niveau dans Hibernate?
Quelqu'un peut-il expliquer avec des mots simples ce que sont la mise en cache de premier et de second niveau dans Hibernate?
1.1) Cache de premier niveau
Cache de premier niveau Toujours associé à l'objet de session . Hibernate utilise ce cache par défaut. Ici, il traite une transaction après l’autre, signifie qu’il ne traitera pas une transaction plusieurs fois. Cela réduit principalement le nombre de requêtes SQL à générer dans une transaction donnée. 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 second niveau
Le cache de second niveau est toujours associé à l'objet Session Factory . Lors de l'exécution des transactions, il charge entre les objets au niveau de Session Factory, de sorte 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, il n’est alors pas nécessaire d’opérer une transaction de base de données. De cette façon, le cache de second niveau fonctionne. Ici, nous pouvons également utiliser le cache de niveau requête.
Cité de: http://javabeat.net/introduction-to-hibernate-caching/
Il existe 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 session par session, alors que la mise en cache de second niveau peut être partagée entre plusieurs sessions.
Voici quelques explications de base sur le cache de veille prolongée ...
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 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 extraite de la base de données et stockée dans le cache de premier niveau associé à une session de veille prolongée. Si nous interrogons à 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 retirée de la session à l'aide de la méthode evict(). Le prochain chargement de cette entité fera à nouveau un appel à la base de données si celle-ci a été supprimée à l'aide de la méthode evict(). L'ensemble du cache de session peut être supprimé à l'aide de la méthode clear(). Il va supprimer toutes les entités stockées dans le cache.
Le cache de second niveau est distinct du cache de premier niveau qui peut être utilisé globalement dans l'étendue de la fabrique de sessions. Le cache de second niveau est créé dans l'étendue 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 session fermée, tous les caches qui lui sont associés meurent et le gestionnaire de cache est également fermé. Chaque fois que la session d'hibernation tente de charger une entité, elle recherche en premier lieu une copie en cache de l'entité dans le cache de premier niveau (associée à une session d'hibernation particulière). Si la 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 second niveau est recherché pour l'entité mise en cache. Si le cache de second niveau contient une entité mise en cache, elle est renvoyée 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, de sorte que le prochain appel à la méthode de chargement pour l'entité renvoie l'entité à partir du cache de premier niveau lui-même, sans qu'il soit nécessaire de revenir au cache de second niveau. Si l'entité n'est pas trouvée dans le cache de premier niveau et dans le cache de second 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 retourner en réponse à la méthode load().
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 a toujours été connue sous le nom d'écriture transactionnelle.
L'écriture en arrière est davantage liée au vidage Hibernate qu'à toute transaction logique ou physique. Pendant une transaction, le vidage peut se produire plusieurs fois.
Les modifications vidées ne sont visibles que 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.
Grâce au cache de premier niveau, Hibernate peut effectuer plusieurs optimisations:
Cache de second niveau
Une solution de cache appropriée devra s’étendre sur plusieurs sessions Hibernate, c’est pourquoi Hibernate prend également en charge un cache de second niveau supplémentaire.
Le cache de second niveau est lié au cycle de vie SessionFactory, il n’est donc détruit que lorsque SessionFactory est fermé (généralement lorsque l’application est en cours de fermeture). Le cache de second niveau est principalement axé sur les entités, même s'il prend également en charge une solution facultative de mise en cache des requêtes.
Pour plus de détails, consultez cet article .
par défaut, NHibernate utilise la mise en cache de premier niveau, basée sur les objets de session. Toutefois, si vous utilisez un environnement multi-serveurs, le cache de premier niveau risque de ne pas être très évolutif, avec quelques problèmes de performances. cela est dû au fait que la base de données doit être très fréquemment consultée, car les données sont distribuées sur plusieurs serveurs. En d’autres termes, NHibernate fournit une mémoire cache prête à l’emploi L1 in-process basique et peu sophistiquée. Cependant, il ne fournit pas les fonctionnalités qu'une solution de mise en cache doit nécessairement 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 associé aux objets de fabrique de session. il réduit le temps nécessaire à la base de données pour augmenter le temps de réponse de l'application.
Cache de premier niveau
L'objet de 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 toute l'application. Une application peut utiliser plusieurs objets de session.
Cache de second niveau
L'objet SessionFactory contient les données de cache de second niveau. Les données stockées dans le cache de second niveau seront disponibles pour l’ensemble de l’application. Mais nous devons l'activer explicitement.