什么是JNDI
原理:在DataSource中事先建立多個(gè)數(shù)據(jù)庫(kù)連接,保存在數(shù)據(jù)庫(kù)連接池中。當(dāng)程序訪問數(shù)據(jù)庫(kù)時(shí),只用從連接池中取空閑狀態(tài)的數(shù)據(jù)庫(kù)連接即可,訪問結(jié)束,銷毀資源,數(shù)據(jù)庫(kù)連接重新回到連接池,這與每次去直接訪問數(shù)據(jù)庫(kù)相比,會(huì)節(jié)省大量時(shí)間和資源。
JNDI( Java Naming and DirectoryInterface ),是Java平臺(tái)的一個(gè)標(biāo)準(zhǔn)擴(kuò)展,提供了一組接口、類和關(guān)于命名空間的概念。如同其它很多Java技術(shù)一樣,JDNI是provider-based的技術(shù),暴露了一個(gè) API和一個(gè)服務(wù)供應(yīng)接口(SPI)。這意味著任何基于名字的技術(shù)都能通過(guò)JNDI而提供服務(wù),只要JNDI支持這項(xiàng)技術(shù)。JNDI目前所支持的技術(shù)包括 LDAP、CORBA Common Object Service(COS)名字服務(wù)、RMI、NDS、DNS、Windows注冊(cè)表等等。很多J2EE技術(shù),包括EJB都依靠JNDI來(lái)組織和定位實(shí)體。可以把它理解為一種將對(duì)象和名字捆綁的技術(shù),對(duì)象工廠負(fù)責(zé)生產(chǎn)出對(duì)象,這些對(duì)象都和唯一的名字綁在一起,外部資源可以通過(guò)名字獲得某對(duì)象的引用。
在javax.naming的包中提供Context接口,提供了兩個(gè)很好用的方法:
<1> void bind( String name , Object object )
將名稱綁定到對(duì)象。所有中間上下文和目標(biāo)上下文(由該名稱最終原子組件以外的其他所有組件指定)都必須已經(jīng)存在。
<2>Object lookup( String name )
檢索指定的對(duì)象。如果 name為空,則返回此上下文的一個(gè)新實(shí)例(該實(shí)例表示與此上下文相同的命名上下文,但其環(huán)境可以獨(dú)立地進(jìn)行修改,而且可以并發(fā)訪問)。
運(yùn)行機(jī)制:
1、首先程序代碼獲取初始化的 JNDI 環(huán)境并且調(diào)用 Context.lookup() 方法從 JNDI 服務(wù)提供者那里獲一個(gè) DataSource 對(duì)象
2、中間層 JNDI 服務(wù)提供者返回一個(gè) DataSource 對(duì)象給當(dāng)前的 Java 應(yīng)用程序這個(gè) DataSource 對(duì)象代表了中間層服務(wù)上現(xiàn)存的緩沖數(shù)據(jù)源
3、應(yīng)用程序調(diào)用 DataSource 對(duì)象的 getConnection() 方法
4、當(dāng) DataSource 對(duì)象的 getConnection() 方法被調(diào)用時(shí),中間層服務(wù)器將查詢數(shù)據(jù)庫(kù)連接緩沖池中有沒有PooledConnection 接口的實(shí)例對(duì)象。這個(gè) PooledConnection 對(duì)象將被用于與數(shù)據(jù)庫(kù)建立物理上的數(shù)據(jù)庫(kù)連接
5、如果在緩沖池中命中了一個(gè)PooledCoonection 對(duì)象那么連接緩沖池將簡(jiǎn)單地更新內(nèi)部的緩沖連接隊(duì)列并將該P(yáng)ooledConnection 對(duì)象返回。如果在緩沖池內(nèi)沒有找到現(xiàn)成的PooledConnection 對(duì)象,那么 ConnectionPoolDataSource 接口將會(huì)被用來(lái)產(chǎn)生一個(gè)新的PooledConnection 對(duì)象并將它返回以便應(yīng)用程序使用
6。中間層服務(wù)器調(diào)用PooledConnection 對(duì)象的 getConnection() 方法以便返還一個(gè) java.sql.Connection 對(duì)象給當(dāng)前的 Java 應(yīng)用程序
7、當(dāng)中間層服務(wù)器調(diào)用PooledConnection 對(duì)象的 getConnection() 方法時(shí), JDBC 數(shù)據(jù)庫(kù)驅(qū)動(dòng)程序?qū)?huì)創(chuàng)建一個(gè) Connection 對(duì)象并且把它返回中間層服務(wù)器
8、中間層服務(wù)器將 Connection 對(duì)象返回給應(yīng)用程序 Java 應(yīng)用程序,可以認(rèn)為這個(gè) Connection 對(duì)象是一個(gè)普通的 JDBC Connection 對(duì)象使用它可以和數(shù)據(jù)庫(kù)建立。事實(shí)上的連接與數(shù)據(jù)庫(kù)引擎產(chǎn)生交互操作。
9、當(dāng)應(yīng)用程序不需要使用 Connection 對(duì)象時(shí),可以調(diào)用 Connection 接口的 close() 方法。請(qǐng)注意這種情況下 close() 方法并沒有關(guān)閉事實(shí)上的數(shù)據(jù)庫(kù)連接,僅僅是釋放了被應(yīng)用程序占用的數(shù)據(jù)庫(kù)連接,并將它還給數(shù)據(jù)庫(kù)連接緩沖池,數(shù)據(jù)庫(kù)連接緩沖池會(huì)自動(dòng)將這個(gè)數(shù)據(jù)庫(kù)連接交給請(qǐng)求隊(duì)列中下一個(gè)的應(yīng)用程序使用。
現(xiàn)在,數(shù)據(jù)庫(kù)的連接沒有用到連接池幾乎很少很少,每個(gè)項(xiàng)目組都可能有自己的數(shù)據(jù)庫(kù)連接池組件,各容器提供商也提供了各自的數(shù)據(jù)庫(kù)連接池,下面介紹一下tomcat的數(shù)據(jù)庫(kù)連接管理。
tomcat6 數(shù)據(jù)源配置(server.xml方式和context.xml方式)
在server.xml下配置你必需重啟服務(wù)器才能生效,而context.xml配置保存后tomcat會(huì)自動(dòng)加載無(wú)需重啟
在JNDI配配置數(shù)據(jù)源中需注意:項(xiàng)目下需要引入數(shù)據(jù)庫(kù)驅(qū)動(dòng)包,并且TOMCAT下也需要引入,不然會(huì)報(bào)錯(cuò)的
1.context.xml方式
Tomcat-6.0.26\conf\context.xml文件當(dāng)添加以下的配置信息:
1
2
3
4
5
6
7
8
|
< Resource name = "jdbc/mysql" auth = "Container" type = "javax.sql.DataSource" maxActive = "100" maxIdle = "30" maxWait = "60" wait_timeout = "18800" timeBetweenEvictionRunsMillis = "300000" minEvictableIdleTimeMillis = "600000" username = "root" password = "jdzxdb" driverClassName = "com.mysql.jdbc.Driver" url = "jdbc:mysql://localhost:3306/sxtele?comautoReconnect=true&failOverReadOnly=false" removeAbandoned = "true" removeAbandonedTimeout = "60" logAbandoned = "true" /> < Resource name = "jdbc/db2" auth = "Container" type = "javax.sql.DataSource" maxActive = "100" maxIdle = "30" maxWait = "60" wait_timeout = "18800" timeBetweenEvictionRunsMillis = "300000" minEvictableIdleTimeMillis = "600000" username = "lcgluser" password = "lcgluser" driverClassName = "com.ibm.db2.jcc.DB2Driver" url = "jdbc:db2://133.64.46.65:50000/STEDWDB" removeAbandoned = "true" removeAbandonedTimeout = "60" logAbandoned = "true" /> |
其中:
name 表示指定的jndi名稱
auth 表示認(rèn)證方式,一般為Container
type 表示數(shù)據(jù)源床型,使用標(biāo)準(zhǔn)的javax.sql.DataSource
maxActive 表示連接池當(dāng)中最大的數(shù)據(jù)庫(kù)連接
maxIdle 表示最大的空閑連接數(shù)
maxWait 當(dāng)池的數(shù)據(jù)庫(kù)連接已經(jīng)被占用的時(shí)候,最大等待時(shí)間
logAbandoned 表示被丟棄的數(shù)據(jù)庫(kù)連接是否做記錄,以便跟蹤
username 表示數(shù)據(jù)庫(kù)用戶名
password 表示數(shù)據(jù)庫(kù)用戶的密碼
driverClassName 表示JDBC DRIVER
url 表示數(shù)據(jù)庫(kù)URL地址
注意,這里你配置的name值要和程序中使用的是一樣的,比如按照這個(gè)例子,程序就應(yīng)該是這樣的,Java代碼:
1
2
3
4
5
6
7
8
|
String gENV = "java:comp/env/" ; Context ctx = new InitialContext(); DataSource ds = (DataSource)ctx.lookup(gENV+ "jdbc/mysql" ); Connection conn =ds.getConnection(); String gENV = "java:comp/env/" ; Context ctx = new InitialContext(); DataSource ds =(DataSource)ctx.lookup(gENV+ "jdbc/db2" ); Connection conn =ds.getConnection(); |
關(guān)于獲取數(shù)據(jù)源的語(yǔ)法,大體有(javax.sql.DataSource) ctx.lookup("java:comp/env/XXX")和(javax.sql.DataSource)ctx.lookup("XXX")兩種寫法,好多人以為這兩種寫法是相同的,以為都是通過(guò)JNDI來(lái)獲取數(shù)據(jù)源。其實(shí)java:comp/env和 JNDI是不同的,java:comp/env 是環(huán)境命名上下文(environmentnaming context(ENC)),是在EJB規(guī)范1.1以后引入的,引入這個(gè)是為了解決原來(lái)JNDI查找所引起的沖突問題,也是為了提高EJB或者J2EE應(yīng)用的移植性。ENC是一個(gè)引用,引用是用于定位企業(yè)應(yīng)用程序的外部資源的邏輯名。引用是在應(yīng)用程序部署描述符文件中定義的。在部署時(shí),引用被綁定到目標(biāo)可操作環(huán)境中資源的物理位置(JNDI名)。使用ENC是把對(duì)其它資源的JNDI查找的硬編碼解脫出來(lái),通過(guò)配置這個(gè)引用可以在不修改代碼的情況下,將引用指向不同的EJB(JNDI)。
什么是JTA
Java Transaction API(Java事務(wù)API)(JTA)Java Transaction API(Application Programming Interface)
什么是JTA Transaction?它有怎樣的特點(diǎn)呢?JTA Transaction是指由J2EE Transaction manager去管理的事務(wù)。其最大的特點(diǎn)是調(diào)用UserTransaction接口的begin,commit和rollback方法來(lái)完成事務(wù)范圍的 界定,事務(wù)的提交和回滾。JTATransaction可以實(shí)現(xiàn)同一事務(wù)對(duì)應(yīng)不同的數(shù)據(jù)庫(kù),但是它仍然無(wú)法實(shí)現(xiàn)事務(wù)的嵌套。
分布式事務(wù)的規(guī)范由OMG的OTS所描述。
JTA是只是一組java接口用于描述,J2ee框架中事務(wù)管理器與應(yīng)用程序,資源管理器,以及應(yīng)用服務(wù)器之間的事務(wù)通訊。
它主要包括高層接口即面向應(yīng)用程序的接口;XAResource接口即面向資源的接口;以及事務(wù)管理器的接口。值得注意的是JTA只提供了接口,沒有具體的實(shí)現(xiàn)。
JTS是服務(wù)OTS的JTA的實(shí)現(xiàn)。簡(jiǎn)單的說(shuō)JTS實(shí)現(xiàn)了JTA接口,并且符合OTS的規(guī)范。
資源管理器只要其提供給事務(wù)管理器的接口符合XA接口規(guī)范,就可以被事務(wù)管理器處理。 所以,JTA可以處理任何提供符合XA接口的資源。包括:數(shù)據(jù)庫(kù),JMS,商業(yè)對(duì)象等等
“Java 事務(wù) API”(JTA)啟用兩階段提交功能。當(dāng)配置WebSphere Application Server 以訪問數(shù)據(jù)庫(kù)時(shí),可選擇具有 JTA 能力的驅(qū)動(dòng)程序。如果需要兩階段提交功能,則必須使用啟用 JTA 的驅(qū)動(dòng)程序。
只要您在事務(wù)中調(diào)用了多個(gè)數(shù)據(jù)庫(kù)連接,就需要 JTA。只要您在事務(wù)中調(diào)用了多個(gè)數(shù)據(jù)庫(kù)服務(wù)器,就需要兩階段提交。這些連接可以是相同的物理數(shù)據(jù)庫(kù)服務(wù)器或多個(gè)數(shù)據(jù)庫(kù)服務(wù)器。例如:
[list=1][*]實(shí)體企業(yè) BeanEntity1 在應(yīng)用程序服務(wù)器 AppServer1 中部署。[*]實(shí)體企業(yè) Bean Entity2 在應(yīng)用程序服務(wù)器AppServer1 中部署。[*]會(huì)話企業(yè) Bean Session1 在應(yīng)用程序服務(wù)器 AppServer1 中部署。[/list]如果Session1 對(duì)同一事務(wù)內(nèi)的 Entity1 和 Entity2 調(diào)用了方法而這兩個(gè)企業(yè) Bean 正在使用不同的物理數(shù)據(jù)庫(kù)連接,則必須對(duì) Entity1 和 Entity2 使用的數(shù)據(jù)源啟用 JTA。當(dāng)從相同的數(shù)據(jù)源對(duì)象獲取那些連接時(shí),這也是成立的。這需要具有 JTA 能力的驅(qū)動(dòng)程序以提交事務(wù)。
當(dāng)事務(wù)涉及到多個(gè)進(jìn)程時(shí),JTA 也是必需的。例如,一個(gè)事務(wù)可能會(huì)涉及在多個(gè)應(yīng)用程序服務(wù)器中部署的企業(yè) Bean。
[list=1][*]實(shí)體企業(yè) BeanEntity1 在應(yīng)用程序服務(wù)器 AppServer1 中部署。[*]實(shí)體企業(yè) Bean Entity2 在應(yīng)用程序服務(wù)器AppServer2 中部署。[*]會(huì)話企業(yè) Bean Session1 在應(yīng)用程序服務(wù)器 AppServer1 中部署。[/list]如果Session1 對(duì)同一事務(wù)(此事務(wù)構(gòu)成一個(gè)分布式事務(wù))內(nèi)的 Entity1 和 Entity2 調(diào)用了方法,則必須對(duì) Entity1 和 Entity2 使用的數(shù)據(jù)源啟用 JTA。
性能實(shí)現(xiàn)JTA 啟用的連接與非 JTA 啟用的連接執(zhí)行情況不同。基于此原因,如果您的應(yīng)用程序不需要 JTA,則最好使用非 JTA 啟用的驅(qū)動(dòng)程序。
其它信息有關(guān) WebSphere Application Server 如何支持 JTA 的信息,參見 WebSphere Application Server 和 DB2UDB iSeries 版的事務(wù)處理及其子主題。
什么是JMS
jms即Java消息服務(wù)(JavaMessage Service)應(yīng)用程序接口是一個(gè)Java平臺(tái)中關(guān)于面向消息中間件(MOM)的API,用于在兩個(gè)應(yīng)用程序之間,或分布式系統(tǒng)中發(fā)送消息,進(jìn)行異步通信。Java消息服務(wù)是一個(gè)與具體平臺(tái)無(wú)關(guān)的API,絕大多數(shù)MOM提供商都對(duì)JMS提供支持。jms同時(shí)也可以指Journal of Marketing Science,《營(yíng)銷科學(xué)學(xué)報(bào)》的簡(jiǎn)稱。此外,佳木斯的拼音縮寫也是jms。
傳遞方式
JMS有兩種傳遞消息的方式。標(biāo)記為NON_PERSISTENT的消息最多投遞一次,而標(biāo)記為PERSISTENT的消息將使用暫存后再轉(zhuǎn)送的機(jī)理投遞。如果一個(gè)JMS服務(wù)離線,那么持久性消息不會(huì)丟失但是得等到這個(gè)服務(wù)恢復(fù)聯(lián)機(jī)時(shí)才會(huì)被傳遞。所以默認(rèn)的消息傳遞方式是非持久性的。即使使用非持久性消息可能降低內(nèi)務(wù)和需要的存儲(chǔ)器,并且這種傳遞方式只有當(dāng)你不需要接收所有的消息時(shí)才使用。
雖然JMS規(guī)范并不需要JMS供應(yīng)商實(shí)現(xiàn)消息的優(yōu)先級(jí)路線,但是它需要遞送加快的消息優(yōu)先于普通級(jí)別的消息。JMS定義了從0到9的優(yōu)先級(jí)路線級(jí)別,0是最低的優(yōu)先級(jí)而9則是最高的。更特殊的是0到4是正常優(yōu)先級(jí)的變化幅度,而5到9是加快的優(yōu)先級(jí)的變化幅度。舉例來(lái)說(shuō): topicPublisher.publish (message, DeliveryMode.PERSISTENT, 8, 10000); //Pub-Sub 或 queueSender.send(message,DeliveryMode.PERSISTENT, 8, 10000);//P2P 這個(gè)代碼片斷,有兩種消息模型,映射遞送方式是持久的,優(yōu)先級(jí)為加快型,生存周期是10000 (以毫秒度量)。如果生存周期設(shè)置為零,這則消息將永遠(yuǎn)不會(huì)過(guò)期。當(dāng)消息需要時(shí)間限制否則將使其無(wú)效時(shí),設(shè)置生存周期是有用的。
總結(jié)
本文關(guān)于JNDI,JTA和JMS簡(jiǎn)介就到這里,希望對(duì)大家有所幫助。
原文鏈接:http://blog.csdn.net/cuiran/article/details/40950487