Hibernate 2e niveau cache dans une application Grails

Question

Partie I

Dans un Graal app, je comprends que vous activez le 2ème niveau de cache par domaine en classe par l'ajout d'

static mapping {
  cache true
}

Par défaut, le 2ème niveau de cache est utilisé uniquement lors de la get() est appelé, mais il peut également être utilisé pour les critères de requêtes et de la dynamique des télémètres par l'ajout d' cache true à la requête.

Cependant, je ne suis toujours pas sûr de comprendre comment le cache de requête fonctionne. Ma meilleure supposition est que:

• il y a de requête distincte de cache pour chaque domaine de la classe, par exemple, un Livre et un autre de l'Auteur
• avant, comme une requête Author.findByName('bob', [cache: true]) est exécutée, une clé de cache est calculée, qui est basé sur le domaine de la classe (Auteur), la requête (findByName) et les paramètres de la requête ("bob"). Si la clé se trouve dans l'Auteur du cache de requêtes, les résultats mis en cache sont retournés à la place de l'exécution de la requête
• tout fois qu'un Auteur est enregistré, supprimés ou mis à jour, l'Auteur de la requête cache est vidé

Cela semble raisonnable jusqu'à ce que nous considérons qu'une requête qui retourne Livre instances peuvent se joindre à l'Auteur de la table. Dans ce cas, il serait nécessaire de rincer la fois le Livre et l'Auteur de la requête caches quand un Auteur est enregistré, supprimés ou mis à jour. Cela m'amène à penser que peut-être il est juste un simple cache de requête et qu'il est effacé à chaque fois que de domaine mis en cache classe est sauvé?

Partie II

Dans le Graal docs il mentionne que

Ainsi que la capacité à utiliser Hibernate du cache de second niveau de cache cas, vous pouvez également mettre en cache les collections (associations) des objets.

Par exemple:

class Author {    

  static hasMany = [books: Book]

  static mapping = { 
    cache true        // Author uses the 2nd level cache
    books cache: true // associated books use the 2nd level cache
  } 
}

class Book {
  static belongsTo = [author: Author]

  static mapping = {
    cache true // Book uses the 2nd level cache
  }
}

La configuration ci-dessus, le sens, c'est à dire si l'Auteur et l'Ouvrage sont eux-mêmes à l'aide de la 2e niveau de cache, est-il un avantage à faire de l'Auteur du Livre de l'association également utiliser le 2ème niveau de cache?

La partie III

Enfin, j'ai lu ce conseil sur l'utilisation de la 2ème niveau du cache de requêtes, ce qui suggère qu'il devrait être utilisé seulement pour rarement évolution des classes du domaine. Existe-il des circonstances dans lesquelles on ne devrait pas permettre à la 2ème niveau de cache pour get() des opérations, c'est à dire aucune raison pourquoi il ne faudrait pas ajouter ce qui suit dans un domaine classe

static mapping = {
  cache true // Book uses the 2nd level cache
}

Answer 1

Partie 1:

Hibernate fait la bonne chose. Le cache de requête n'est pas par entité. Il y a une seule requête région de cache partagé par toutes les requêtes, sauf si vous définissez une région spécifique pour une requête. Chaque fois qu'une table est mise à jour, son timestamp dans les horodateurs cache est mis à jour. Chaque fois qu'une requête est exécutée, l'horodatage de chaque table où la requête de recherche est par rapport à l'heure de la mise en cache du résultat. Et bien sûr, la mise en cache le résultat est renvoyé que si itstimestamp est plus récente que celle de la table des horodateurs.

Partie 2:

Oui, c'est logique. Le cache pour que l'auteur se souvient que l'auteur avec l'ID 456 porte le nom "foo", et la date de naissance 1975/07/19. Seules les données stockées dans l'auteur de la table se souvient. Ainsi, la mise en cache de l'association est également utile: au lieu de faire une requête supplémentaire pour obtenir l'ensemble des livres de l'auteur lors de l'appel d' author.getBooks(), Hibernate va obtenir les Id des livres de l'auteur à partir de son cache, puis de charger chaque livre de la cache de second niveau. Assurez-vous de mettre en cache les Livres, bien que.

Partie 3:

Je peux imaginer plusieurs raisons:

• il ya tellement de nombreuses entités et ils sont à changer ainsi que le nombre de cache serait très faible, et que le cache de second niveau de la manipulation serait en fait consommer plus de temps et de mémoire qu'une solution sans cache
• l'application en cluster, et le coût et la complexité d'un système distribué, le cache de second niveau est trop élevé, pour un faible gain
• d'autres non-applications hibernate écrire à la même base de données et le cache a donc un grand risque de retour des données obsolètes, ce qui n'est pas acceptable
• tout va très bien sans un cache de second niveau, et il n'y a pas de raison de rendre l'application plus complexe qu'elle ne l'est.