EJB et Hibernate dans l'application Struts

Question

J'ai une application qui a une combinaison de struts 1.1 et EJB 2, mais maintenant nous introduisons une nouvelle pièce avec hibernate 3.2. Les DAO hibernate s'exécutent en parallèle avec les DAO EJB 2 du bean session avec du JDBC pur. Je suis préoccupé par la gestion des connexions jdbc dans ce cas. Depuis EJB 2.0 a des connexions et des transactions gérées par conteneur. Mais dans le cas d'hibernate nous commençons et commettons une transaction d'hibernation, Sera-t-il sûr de ne pas avoir de problèmes avec cette architecture.

Besoin d'aide pour l'analyse.

PM

---

je contemplais sur la même question, si le module de mise en veille prolongée qui pourrait accéder à des tables existantes utilisées par JDBC de DAO dont la transaction est gérée par Beans session. Mais voici mon approche:

1. Je vais avoir un délégué qui appelle le bean de session EJB, et puisque ce haricot sera responsable de gérer les transactions, je vais créer ma mise en veille prolongée OAC de et les appeler de cette bean session, ce que je suppose n'aura aucun problème. La fabrique de sessions Hibernate pour cette application sera instanciée une fois en utilisant le plugin hibernate qui fera partie de la configuration de struts xml et sera sauvegardée dans le contexte du servlet, puis la classe action passera cette instance de sessionfactory de le délégué EJB du bean session au DAO Hibernate.

2. Je suppose que ce sera une approche propre, puisque la transaction sera gérée par le bean Session EJB qui est déployé sur la websphere. La gestion des pools de connexions JDBC étant configurée sur la websphere et accessible avec les sources de données, hibernate n'a pas à se soucier de cela.

S'il vous plaît aidez-moi si je suis sur le bon chemin avec mes hypothèses?

Answer 1

Les opérations délimitent l'unité de travail logique et sont par conséquent isolées de manière inhérente. Mais je me demande pourquoi vous avez besoin d'une combinaison des deux. Si vous utilisez déjà EJB2 + JDBC pourquoi ne pas s'en tenir à cela?

Answer 2

Hibernate peut être utilisé sans problème avec les beans session CMT (ou BMT), partager un pool de connexions avec du code JDBC et participer à la même transaction. Voir la section complète 11.2. Database transaction demarcation et en particulier 11.2.2. Using JTA. Ce qui n'est pas clair, c'est si le module Hibernate sera "isolé" des entités gérées via JDBC. Si vous accédez aux mêmes tables via les API, vous devrez prendre quelques précautions:

• ne vous attendez pas à mélanger les entités JDBC dans un graphique d'entités Hibernate (l'inverse est cependant possible).
• respect et mimétique Hibernate stratégie optimiste de concurrence lorsque la mise à jour des lignes via JDBC
• sans passer par l'API Hibernate ne déclenche pas une mise à jour du cache (si vous utilisez le 2ème cache de niveau) auquel cas vous auriez à déclencher vous-même .

Answer 3

Voici une des solutions possibles

Une source de données JNDI commune, qui seront utilisés aussi bien dans EJB et Hibernate.