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.EJB et Hibernate dans l'application Struts
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:
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.
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?
Hibernate devrait participer à vos transactions gérées par conteneur, vous ne devriez pas avoir besoin d'un service parallèle. Je pense que vous avez raison d'être inquiet parce que ce que vous décrivez ne sent pas bon. –