DataSource pour l'application Web Tomcat, Spring et Hibernate

Question

L'application Web s'exécute sur Tomcat. La source de données est configurée avec la configuration Spring, et est utilisée par Hibernate.

Si nous ne pouvons pas utiliser JNDI, que suggéreriez-vous d'utiliser comme DataSource?

org.springframework.jdbc.datasource.DriverManagerDataSource sera ok? Ce n'est pas très bon, mais sincèrement, il peut être utilisé sur le serveur de production, non? Juste un peu de mal de tête avec une réouverture de connexion trop fréquente.

De plus, nous pouvons utiliser BasicDataSource d'Apache. C'est beaucoup mieux, bien sûr, mais voici la question. SI NOUS N'EMPLOYONS PAS JNDI, PUIS:


Si chaque instance d'une application va créer sa propre copie d'une DataSource, et que chaque DataSource peut avoir 5 connexions ouvertes, qu'obtenons-nous?
Num_of_running_apps * Num_of_max_active_connections = connexion ouverte maximale active sur un DB pour cet utilisateur?

Deuxième question: dans la perspective de mise en veille prolongée, est-il une différence sur ce que la mise en œuvre DataSource est utilisé? Cela fonctionnera-t-il avec n'importe quelle source de données parfaitement et de manière stable?

Answer 1

Si nous ne pouvons pas utiliser JNDI, que suggéreriez-vous d'utiliser comme DataSource?

Certainement pas org.springframework.jdbc.datasource.DriverManagerDataSource dans la production, cette classe est tout simplement pas un pool de connexion comme écrit dans le javadoc:

NOTE: Cette classe n'est pas une piscine de connexion réelle; il ne regroupe pas réellement les connexions. Il sert simplement de remplacement pour un pool de connexions complet, implémentant la même interface standard, mais créant de nouvelles connexions à chaque appel.

Utile pour les environnements de test ou autonome en dehors d'un conteneur J2EE, soit en tant que bean DataSource dans un ApplicationContext correspondant, soit en conjonction avec un environnement JNDI simple. Pool-en supposant que Connection.close() les appels ferment simplement la connexion, donc tout code de persistance DataSource-aware devrait fonctionner.

Utilisez un pool de connexion autonome comme C3P0 ou DBPC. Personnellement, je voudrais aller pour C3P0 qui est connu pour se comporter mieux que DBCP. Jetez un oeil à c3p0 vs. dbcp sur les forums de printemps et ce previous question ici sur SO.

Si chaque instance d'une application crée sa propre copie d'une source de données et que chaque source de données peut avoir 5 connexions ouvertes, que pouvons-nous obtenir?

Nombre total de connexions = Nombre d'instances de l'application x 5

du point de vue de mise en veille prolongée, est-il une différence sur ce que la mise en œuvre DataSource est utilisé?

Il n'y a pas de différence. Hibernate utilisera la connexion, il obtient du printemps.