解决方案 »

  1.   

    JNDI 只是一种资源管理方式
    C3P0是数据源连接池的配置方式
    这两个不能直接用来比较吧,使用JNDI管理数据库连接池,连接池可以使用C3P0,也可是使用DBCP等方式
      

  2.   

    jndi是命名服务,和数据源技术没有重复的方面,没什么太大关联的2种技术。没任何可比性。
      

  3.   

    使用JNDI 是为了数据库资源的管理,在容器中配置一个数据库连接池,使用JNDI 来管理
    这样容器中运行多个服务的时候,每个服务只需添加一个jndi的名称就可以连接到数据库了
    如果不使用jndi的方式,直接在项目中配置数据库连接池,那么每个项目需要配置一次,如果更改数据库地址时,每个项目的数据库连接方式都要更改,比较麻烦
    使用jndi的话,直接更改一下jndi里面的数据库连接池的配置就可以了,方便一些。
      

  4.   

    jndi不是连接池,拿来和c3p0怎么比回去打“别人”的脸吧
      

  5.   

    他俩不是一个东西,JNDI从抽象层面上来看要在C3P0上层,也就是说JNDI提供的服务是有可能由C3P0和其他包来实现的。
      

  6.   

    一般来说如果目标客户肯定有专业的应用服务器,比如 WebSphere 啥的,我们就不需要在代码中配置使用特定的 dbcp 或其它的连接池了,代码中只使用 JNDI 查找资源,将来部署到服务器上时在服务器上配置数据源(服务器帮我们准备了连接池实现方法)。有时候我们可能觉得使用自己的配置的连接池代码不用配置部署到任意服务器上都能用,这种理解其实没有明白 J2EE 开发为什么需要那么多的规范,你不能假设或强制你的客户必须使用你的方案,比如对一个大企业来说,它的一台应用服务器可能上面运行很多种独立应用程序,还可能与其它不同编程语言开发出来的组件服务互操作(分布式调用都有可能,负载均衡,故障容错),这些地方如果你要用自己的办法做就表示你的应用程序没打算与它们进行交互,将来新增功能时可能就需要改动你原来的设计。当然对于只是一个独立的 web 应用程序来说也确实不需要考虑太多,我们需要先明白客户的企业应用生态系统是什么样的,我们的应用程序在他们的森林中处在哪个位置是什么角色。