【问题标题】:How to deal with connection pooling and DAOs?如何处理连接池和 DAO?
【发布时间】:2017-10-26 20:31:16
【问题描述】:

我正在学习JDBC 连接池,使用JNDI 获得DataSource 实例听起来相对容易:

DataSource ds = (DataSource)ctx.lookup("jdbc/myDB");

我发现的所有教程仅在一个对象中显示此代码,但我的问题是当我有多个需要从数据库中获取数据的 DAO 对象时如何使用 DataSource

  1. 可以在每个新的DAO 对象的构造函数上使用上面的代码进行连接池吗? 我认为每次都会返回相同的DataSource,就像字典一样单身人士会这样做,持有一个 DataSource 并返回它,或者我错了,它会每次返回不同的 DataSource 并使用不同的池,从而违背我的目的吗?

  2. 我应该在 Singleton 中保留 DataSource 并且只运行一次 JNDI 搜索,还是搜索开销可以忽略,这是一个愚蠢的优化?

【问题讨论】:

标签: java datasource jndi connection-pooling


【解决方案1】:
  1. 是否可以在每个新 DAO 对象的构造函数上使用上述代码进行连接池?我认为每次都会返回相同的 DataSource,就像 Dictionary Singleton 会做的那样,持有一个 DataSource 并返回它,或者我错了,它会每次返回不同的 DataSource 并使用不同的池,从而违背我的目的吗?

每次都应该返回相同的 DataSource 对象。如果它实际上不是同一个对象,那么它至少应该共享相同的底层连接池。

  1. 我应该将 DataSource 保存在 Singleton 中并且只运行一次 JNDI 搜索,还是应该忽略搜索开销,这是一个愚蠢的优化?

与在远程数据库上执行操作相比,JNDI 的搜索开销可以忽略不计,因此不需要缓存 DataSource 对象。

【讨论】:

  • 这是人们在 DAO 上使用它的方式吗?还是有其他著名的模式?
  • 首先我要问,你是在 Java EE 应用服务器上运行还是不在?
  • 我在 tomcat 8 上运行...但是为什么这很重要?这不应该与带下划线的平台脱钩吗?
  • 不一定,应用服务器提供了编写代码时应考虑的价值。在这种情况下,tomcat 提供了连接池,因此应用程序(您)不需要担心它。
  • 是的,但据我了解,在我将 tomcat 配置为使用连接池之后,其余部分几乎是透明的......所以即使我有机会用 tomcat 做其他事情,JNDI 也会调用在我的 DAO 上检索数据源应该保持不变
猜你喜欢
  • 2012-09-30
  • 1970-01-01
  • 2015-06-18
  • 1970-01-01
  • 2017-10-16
  • 1970-01-01
  • 2010-09-22
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多