jndi就是一个目录命名服务器。它里面实现了连接池。根据jndi名字就能找到相应的连接。JDBC是每次都要向数据库申请创建连接,但申请的数量大的时候就慢了。数据连接池能在系统闲置的时候创建一定数量的数据库链接放在池中。要连接时来拿一个就行了肯定是jdni效率高。不能说节省资源。
你说的javaee环境还真抽象。
如果是用的jboss:
那么jboss中可以配置jboss自己的jms。
在有些应用中,我们不需要在程序启动的时候就启动JMS服务;而且,我们每次访问的JMS服务器有可能都不一样,这个时候就需要一个可动态配置JMS ConnectionFactory 。
<!-- JMS -->
<!-- JNDI Template -->
<bean id="jndiTemplate" class="orgspringframeworkjndiJndiTemplate" lazy-init="true">
<property name="environment">
<props>
<prop key="javanamingfactoryinitial">orgjnpinterfacesNamingContextFactory</prop>
<prop key="javanamingfactoryurlpkgs">orgjbossnaming:orgjnpinterfaces</prop>
<prop key="javanamingproviderurl">localhost:1099</prop>
</props>
</property>
</bean>
<!-- JMS Connection --> <bean id="jmsConnectionFactory" lazy-init="true" class="orgspringframeworkjndiJndiObjectFactoryBean">
<property name="proxyInterfaces" value="javaxjmsConnectionFactory" />
<property name="lookupOnStartup" value="false" />
<property name="jndiTemplate" ref="jndiTemplate" />
<property name="jndiName" value
tyle="color: rgb(0, 0, 255);">="ConnectionFactory" />
</bean>
<!-- userCredentialsConnection For JmsSecurity -->
<bean id="myConnectionFactory" lazy-init="true"
class="orgspringframeworkjmsconnectionUserCredentialsConnectionFactoryAdapter">
<property name="targetConnectionFactory" ref="jmsConnectionFactory" />
</bean>
我们可以通过代码来重新配置JMS服务器的IP和Security的用户名和密码
if (StringUtilsisNotEmpty(hostName)) {
JndiTemplate jndiTemplate = (JndiTemplate) thisfactorygetBean("jndiTemplate");
Properties props = jndiTemplategetEnvironment();
propssetProperty("javanamingproviderurl", hostName + ":1099");
}
UserCredentialsConnectionFactoryAdapter jmsUserAdapter = (UserCredentialsConnectionFactoryAdapter)
thisfactorygetBean("myConnectionFactory");
jmsUserAdaptersetUsername(jmsUserName);
jmsUserAdaptersetPassword(jmsPassword);
JNDI是J2EE应用中一个很重要的概念,初学时很难理解JNDI在J2EE中的角色。简单说JNDI的作用就是使我们自己编写的代码和代码中用到的外部组件(例如:DataSource)解耦。
一般来讲在用JDBC访问数据库时需要在代码中指定数据库驱动、数据库URL等等,很显然在项目的开发、测试、部署阶段这些信息会有所不同,那么就要相应改动代码、重新编译、测试、部署等等,而这恰恰是我们不希望的。那么我们就可以在代码中指定一些不变的逻辑地址,然后让JNDI通过逻辑地址找到物理地址,再将逻辑地址和物理地址的对应关系放在配置文件中,而这些配置文件是由实现JNDI的J2EE服务器管理的,这样当更改数据源时就无需重新编译、打包部署了。我们编写的代码也就和具体用到的外部组件解耦了。
JNDI不仅仅用于JDBC数据源,它同样可以应用于EJB组件的查找。
JNDI是 Java 命名与目录接口(Java Naming and Directory Interface),在J2EE规范中是重要的规范之一,不少专家认为,没有透彻理解JNDI的意义和作用,就没有真正掌握J2EE特别是EJB的知识。
那么,JNDI到底起什么作用?
要了解JNDI的作用,我们可以从“如果不用JNDI我们怎样做?用了JNDI后我们又将怎样做?”这个问题来探讨。
没有JNDI的做法:
程序员开发时,知道要开发访问MySQL数据库的应用,于是将一个对 MySQL JDBC 驱动程序类的引用进行了编码,并通过使用适当的 JDBC URL 连接到数据库。
就像以下代码这样:
Java code
Connection conn=null;
try {
ClassforName("commysqljdbcDriver",
true, ThreadcurrentThread()getContextClassLoader());
conn=DriverManagergetConnection("jdbc:mysql://MyDBServeruser=qingfeng&password=mingyue");
connclose();
}
catch(Exception e) {
eprintStackTrace();
}
finally {
if(conn!=null) {
try {
connclose();
} catch(SQLException e) {}
}
}
这是传统的做法,也是以前非Java程序员(如Delphi、VB等)常见的做法。这种做法一般在小规模的开发过程中不会产生问题,只要程序员熟悉Java语言、了解JDBC技术和MySQL,可以很快开发出相应的应用程序。
没有JNDI的做法存在的问题:
1、数据库服务器名称MyDBServer 、用户名和口令都可能需要改变,由此引发JDBC URL需要修改;
2、数据库可能改用别的产品,如改用DB2或者Oracle,引发JDBC驱动程序包和类名需要修改;
3、随着实际使用终端的增加,原配置的连接池参数可能需要调整;
4、
解决办法:
程序员应该不需要关心“具体的数据库后台是什么?JDBC驱动程序是什么?JDBC URL格式是什么?访问数据库的用户名和口令是什么?”等等这些问题,程序员编写的程序应该没有对 JDBC 驱动程序的引用,没有服务器名称,没有用户名称或口令 —— 甚至没有数据库池或连接管理。而是把这些问题交给J2EE容器来配置和管理,程序员只需要对这些配置和管理进行引用即可。
由此,就有了JNDI。
用了JNDI之后的做法:
首先,在在J2EE容器中配置JNDI参数,定义一个数据源,也就是JDBC引用参数,给这个数据源设置一个名称;然后,在程序中,通过数据源名称引用数据源从而访问后台数据库。
具体 *** 作如下(以JBoss为例):
1、配置数据源
在JBoss 的 D:\jboss420GA\docs\examples\jca 文件夹下面,有很多不同数据库引用的数据源定义模板。将其中的 mysql-dsxml 文件Copy到你使用的服务器下,如 D:\jboss420GA\server\default\deploy。
修改 mysql-dsxml 文件的内容,使之能通过JDBC正确访问你的MySQL数据库,如下:
<xml version="10" encoding="UTF-8">
<datasources>
<local-tx-datasource>
<jndi-name>MySqlDS </jndi-name>
<connection-url>jdbc:mysql://localhost:3306/lw </connection-url>
<driver-class>commysqljdbcDriver </driver-class>
<user-name>root </user-name>
<password>rootpassword </password>
<exception-sorter-class-name>orgjbossresourceadapterjdbcvendorMySQLExceptionSorter </exception-sorter-class-name>
<metadata>
<type-mapping>mySQL </type-mapping>
</metadata>
</local-tx-datasource>
</datasources>
这里,定义了一个名为MySqlDS的数据源,其参数包括JDBC的URL,驱动类名,用户名及密码等。
2、在程序中引用数据源:
Java code
Connection conn=null;
try {
Context ctx=new InitialContext();
Object datasourceRef=ctxlookup("java:MySqlDS"); //引用数据源
DataSource ds=(Datasource)datasourceRef;
conn=dsgetConnection();
cclose();
}
catch(Exception e) {
eprintStackTrace();
}
finally {
if(conn!=null) {
try {
connclose();
} catch(SQLException e) { }
}
}
直接使用JDBC或者通过JNDI引用数据源的编程代码量相差无几,但是现在的程序可以不用关心具体JDBC参数了。
在系统部署后,如果数据库的相关参数变更,只需要重新配置 mysql-dsxml 修改其中的JDBC参数,只要保证数据源的名称不变,那么程序源代码就无需修改。
由此可见,JNDI避免了程序与数据库之间的紧耦合,使应用更加易于配置、易于部署。
JNDI的扩展:
JNDI在满足了数据源配置的要求的基础上,还进一步扩充了作用:所有与系统外部的资源的引用,都可以通过JNDI定义和引用。
所以,在J2EE规范中,J2EE 中的资源并不局限于 JDBC 数据源。引用的类型有很多,其中包括资源引用(已经讨论过)、环境实体和 EJB 引用。特别是 EJB 引用,它暴露了 JNDI 在 J2EE 中的另外一项关键角色:查找其他应用程序组件。
EJB 的 JNDI 引用非常类似于 JDBC 资源的引用。在服务趋于转换的环境中,这是一种很有效的方法。可以对应用程序架构中所得到的所有组件进行这类配置管理,从 EJB 组件到 JMS 队列和主题,再到简单配置字符串或其他对象,这可以降低随时间的推移服务变更所产生的维护成本,同时还可以简化部署,减少集成工作。外部资源”。
总结:
J2EE 规范要求所有 J2EE 容器都要提供 JNDI 规范的实现。JNDI 在 J2EE 中的角色就是“交换机” —— J2EE 组件在运行时间接地查找其他组件、资源或服务的通用机制。在多数情况下,提供 JNDI 供应者的容器可以充当有限的数据存储,这样管理员就可以设置应用程序的执行属性,并让其他应用程序引用这些属性(Java 管理扩展(Java Management Extensions,JMX)也可以用作这个目的)。JNDI 在 J2EE 应用程序中的主要角色就是提供间接层,这样组件就可以发现所需要的资源,而不用了解这些间接性。
在 J2EE 中,JNDI 是把 J2EE 应用程序合在一起的粘合剂,JNDI 提供的间接寻址允许跨企业交付可伸缩的、功能强大且很灵活的应用程序。这是 J2EE 的承诺,而且经过一些计划和预先考虑,这个承诺是完全可以实现的。
配置数据源,就是配置数据库以及连接池的信息;比如:数据库url,最大连接数等等;
tomcat自带连接池 tomcat-dbcpjar,但是如果用其他连接池就需要加jar包;
1jndi是 Java 命名与目录接口(Java Naming and Directory Interface);
你在配置数据源时,实在xml中配置的;直接使用字符信息获取连接这种方式叫JNDI;
例如:
Context ctx=new InitialContext(); Object datasourceRef=ctxlookup("java:数据源名称"); //引用数据源 DataSource ds=(Datasource)datasourceRef; conn=dsgetConnection();
2c3p0是一个数据库连接池,数据库连接池主要是控制最大连接数、最小连接数等等连接信息
以上就是关于java数据库连接jdbc与jndi全部的内容,包括:java数据库连接jdbc与jndi、在JavaEE环境下,如何通过JNDI获得JMS管理对象ConnectionFactory和Destination急急急急!!!!、深刻理解java的高手进来帮帮我等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)