Hibernate Cache de second niveau en cas de suppression logicielle

Question

Les opérations de lecture sont très élevées par rapport à l'insertion/mise à jour/suppression pour le module de données maître. Nous utilisons JDBC pour les opérations de lecture, d'écriture et de mise à jour jusqu'à maintenant. Nous effectuons une suppression logicielle (marquage de la colonne IS_DELETED sur "Y") lors d'une opération de suppression. Toutes les méthodes d'écriture/mise à jour sont synchronisées pour gérer la concurrence. Nous utilisons Oracle et n'avons aucun plan pour prendre en charge plusieurs bases de données.

Maintenant, nous prévoyons de mettre en cache les données et nous avons également l'intention d'opter pour le clustering. L'option la plus simple est de changer les méthodes insert/update/delete et d'utiliser quelque chose comme ehcache pour gérer le cache selon notre exigence et gérer la concurrence dans l'environnement en cluster en utilisant la colonne version dans la table et supprimer le mot-clé synchronized . L'autre option que les gens autour de moi suggèrent (Infact me demandant de faire) est de passer à l'hibernation (je ne sais pas grand-chose sur hibernate) qui s'occupera automatiquement de la mise en cache et de la concurrence.

Voici mes doutes:

1) Est-il vaut la peine de changer le code complet de DAO donné, nous avons environ 200 tables pour Mangage les données de base?. 2) Hibernerait l'aide du cache de second niveau dans ce cas étant donné que nous devons filtrer à nouveau les données mises en cache pour éliminer les lignes supprimées ou il y a un mécanisme en hibernation (ou autre) par lequel nous pouvons effectuer une opération de mise à jour dans la base de données mais supprimer l'opération dans les données en cache? 3) Nous avons exposé les objets de transfert de données à d'autres modules ayant tous les champs de la table avec la clé primaire stockée dans les objets PK séparés (ayant des champs clés primaires dans un objet séparé) et nous n'avons pas de référence dedans (Composite DO ne sont pas là). Étant donné, Nous ne pouvons pas nous permettre de changer les méthodes exposées et la structure DO - de même devons-nous emballer les données des entités mises en cache d'hibernation dans notre DO? Ou nous pouvons réutiliser l'ancienne structure DO en tant qu'entité hibernate (As: ma colonne PK sous-jacente devrait être là directement dans l'entité hibenate plutôt que dans un objet composite). J'ai mentionné le DO composite car nous avons aussi une exigence de liste déroulante dépendante qui aurait pu être utilisée avec le chargement paresseux en hibernation pour les objets enfants si nous avions un DO composite en premier lieu. L'argument contre est de fournir de nouvelles méthodes qui utiliseraient des données mises en cache et de supprimer les anciennes méthodes. D'autres modules migreraient lentement selon leur besoin de mise en cache, mais nous aurons des problèmes de maintenance car nous devons maintenir les deux méthodes en cas de modification de la base de données. Aussi, 1 et 2 doutes sont toujours là. Je suis sûr qu'Hibernate n'est pas la voie à suivre pour nous à ce stade et je dois convaincre les gens autour de moi mais je veux connaître votre point de vue sur les avantages à long terme de passer en hibernation autre que la gestion automatique de second niveau cache, gestion de la concurrence (Pouvons-nous faire par un petit changement de code à l'endroit commun) et l'indépendance db (Nous ne sommes pas intéressés) sur le coût de la modification du code complet.

Answer 1

Si vous envisagez de migrer vers vous hibernate prendre en compte 1) Vous aurez besoin de la carte toute votre structure de POJO (si vous avez pas déjà) 2) Réécrire utiliser Mise en veille prolongée de tous les OAC (nu à l'esprit 3) Soyez prêt à combattre les problèmes d'initialisation paresseux et ainsi de suite ... Personnellement, je ne pense pas qu'il vaut la peine de passer en mode hibernation avec un modèle de travail, à moins qu'il ne soit extrêmement pénible de maintenir le modèle actuel

En ce qui concerne vos questions 2 et 3 2) Le cache de second niveau contient uniquement les instances chargées, accessibles par la clé primaire. c'est-à-dire si vous dites hibernateSession.load (User, 10) - il recherchera l'objet User dans le cache de second niveau en utilisant id = 10. Si je comprends bien, ce n'est pas le cas. La plupart du temps, vous voulez charger vos données en utilisant une requête plus complexe - dans ce cas, vous aurez besoin de StandarQueryCache, qui mappera votre chaîne de requête à une liste d'ID chargés qui seront à leur tour récupérés du cache de second niveau. Mais si vous avez beaucoup de requêtes avec une faible similarité - StandartQueryCache et le cache de second niveau seront totalement inutiles (jetez un oeil http://darren.oldag.net/2008/11/hibernate-query-cache-dirty-little_04.html) 3) Vous pouvez utiliser des composants et autres, mais je ne suis pas sûr de votre structure DTO.

espoir qui aide