连接池还是数据源?我应该在JNDI中放入哪个?

在 JNDI 级别还是在 Web 应用程序级别连接池更有意义?例如,我可以简单地在javax.sql.DataSource上创建:

<Context antiJARLocking="true">
  <Resource name="jdbc/myDataSource" 
    auth="Container"
    type="javax.sql.DataSource" 
    driverClassName="com.mysql.jdbc.Driver"
    url="jdbc:mysql://localhost/myDataSource" user="user" password="password" />
</Context>

然后在春季配置池,如下所示:

<bean id="myDataSource" class="com.mchange.v2.c3p0.DataSources"
  factory-method="pooledDataSource">
  <constructor-arg>
    <jee:jndi-lookup jndi-name="java:comp/env/jdbc/myDataSource" />
  </constructor-arg>
</bean>

或者,我可以直接在 JNDI 本身中配置池:

<Resource name="jdbc/myDataSource" 
  auth="Container"
  factory="org.apache.naming.factory.BeanFactory"
  type="com.mchange.v2.c3p0.ComboPooledDataSource" 
  driverClassName="com.mysql.jdbc.Driver"
  jdbcUrl="jdbc:mysql://localhost/myDataSource" 
  user="user" password="password"
  minPoolSize="3" 
  maxPoolSize="15" 
  maxIdleTime="5000"
  idleConnectionTestPeriod="300" 
  acquireIncrement="3" />

今年春天离开:

<jee:jndi-lookup id="myDataSource" jndi-name="java:comp/env/jdbc/myDataSource" />

在这两种情况下,myDataSource spring bean 都是 c3p0 连接池数据源,但哪一个更好?我认为在JNDI中拥有池是最有意义的,但缺点是您必须将c3p0 lib推送到servlet容器级别,如果它们当前使用不同的版本,这可能会导致与现有servlet发生冲突。但是,将其放入 JNDI 意味着您的应用程序根本不需要担心池化。你们怎么看?


答案 1

您不需要池化从 JNDI 获取的数据源,因为它已经池化:)

拥有容器管理器池与应用程序池之间的唯一区别是,在第一种情况下,您可以使用标准接口(例如 JBoss 控制台)监视池上的工作负载。然后,如有必要,应用程序服务器的管理员将管理有关增加池大小的决策。他还可以将应用程序切换到另一个数据库服务器(例如,计划从MySQL迁移到Oracle)。缺点是,为单元测试设置 JNDI 测试数据源需要稍多的工作量(请参阅此处)。

在第二种情况下,是的,您必须将DBCP或c3p0以及JDBC驱动程序与应用程序一起打包。在这种情况下,收集有关在Tomcat中运行的所有应用程序的所有池的统计信息并不容易。此外,无法同时为所有应用程序迁移到较新的 JDBC 驱动程序(MySQL 4 到 MySQL 5)。连接属性连接到应用程序,即使您使用文件(因此更改需要重新组合和重新部署项目)。也许你不需要所有这些,因为你只有应用程序,一个数据库,没有管理开销。.property

有关此主题的更多主题:


答案 2

推荐