Question

J'ai une grande application qui utilise les beans entité EJB 2.x (BMP). C’est bien connu pour être une stratégie de persistance horrible (je peux élaborer si nécessaire).

J'aimerais commencer à migrer cette application pour utiliser une stratégie de persistance beaucoup plus expressive, transparente et non invasive. Compte tenu de l'expérience antérieure de mon entreprise, Hibernate 3.x est le choix évident.

La migration vers Hibernate va prendre un certain temps, car plus de 100 tables de l'application utilisent des beans entity. Je cherche donc une approche par étapes dans laquelle les deux stratégies de persistance fonctionnent en parallèle, idéalement sur les mêmes tables en même temps, si possible.

Ma question est la suivante: quels sont les pièges (le cas échéant) de la combinaison de ces deux stratégies de persistance? Vont-ils se gêner?

Était-ce utile?

La solution

Comme dit jodonnel, vous devez faire attention à la mise en cache, car si vous utilisez la mise en cache de second niveau dans Hibernate et qu’une table est modifiée en dehors de Hibernate, Hibernate n’a aucun moyen de savoir que son entrée de cache est périmée.

Pour les transactions, ils doivent tous les deux utiliser JTA fourni par le conteneur, donc pour qu'il soit sûr.

Autres conseils

Je suppose que la chose à laquelle il faut vraiment faire attention est de travailler avec les sessions Hibernate. Hibernate cache des trucs, ce qui pourrait gêner.

Franchement, je recommanderais que, si vous adoptiez Hibernate, supprimiez complètement les beans Entity. Travaillez dans Hibernate avec les beans de session et laissez-les gérer vos transactions.

Vous pouvez également utiliser EJB 3, standardisé par Hibernate dans l'API Java Persistence.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top