什么是JNDI

原理：在DataSource中事先建立多個數據庫連接，保存在數據庫連接池中。當程序訪問數據庫時，只用從連接池中取空閑狀態的數據庫連接即可，訪問結束，銷毀資源，數據庫連接重新回到連接池，這與每次去直接訪問數據庫相比，會節省大量時間和資源。

JNDI( Java Naming and DirectoryInterface )，是Java平臺的一個標準擴展，提供了一組接口、類和關于命名空間的概念。如同其它很多Java技術一樣，JDNI是provider-based的技術，暴露了一個 API和一個服務供應接口（SPI）。這意味著任何基于名字的技術都能通過JNDI而提供服務，只要JNDI支持這項技術。JNDI目前所支持的技術包括 LDAP、CORBA Common Object Service（COS）名字服務、RMI、NDS、DNS、Windows注冊表等等。很多J2EE技術，包括EJB都依靠JNDI來組織和定位實體。可以把它理解為一種將對象和名字捆綁的技術，對象工廠負責生產出對象，這些對象都和唯一的名字綁在一起，外部資源可以通過名字獲得某對象的引用。

在javax.naming的包中提供Context接口，提供了兩個很好用的方法：

<1> void bind( String name , Object object )

將名稱綁定到對象。所有中間上下文和目標上下文（由該名稱最終原子組件以外的其他所有組件指定）都必須已經存在。

<2>Object lookup( String name )

檢索指定的對象。如果 name為空，則返回此上下文的一個新實例（該實例表示與此上下文相同的命名上下文，但其環境可以獨立地進行修改，而且可以并發訪問）。

運行機制：

1、首先程序代碼獲取初始化的 JNDI 環境并且調用 Context.lookup() 方法從 JNDI 服務提供者那里獲一個 DataSource 對象

2、中間層 JNDI 服務提供者返回一個 DataSource 對象給當前的 Java 應用程序這個 DataSource 對象代表了中間層服務上現存的緩沖數據源

3、應用程序調用 DataSource 對象的 getConnection() 方法

4、當 DataSource 對象的 getConnection() 方法被調用時，中間層服務器將查詢數據庫連接緩沖池中有沒有PooledConnection 接口的實例對象。這個 PooledConnection 對象將被用于與數據庫建立物理上的數據庫連接

5、如果在緩沖池中命中了一個PooledCoonection 對象那么連接緩沖池將簡單地更新內部的緩沖連接隊列并將該PooledConnection 對象返回。如果在緩沖池內沒有找到現成的PooledConnection 對象，那么 ConnectionPoolDataSource 接口將會被用來產生一個新的PooledConnection 對象并將它返回以便應用程序使用

6。中間層服務器調用PooledConnection 對象的 getConnection() 方法以便返還一個 java.sql.Connection 對象給當前的 Java 應用程序

7、當中間層服務器調用PooledConnection 對象的 getConnection() 方法時， JDBC 數據庫驅動程序將會創建一個 Connection 對象并且把它返回中間層服務器

8、中間層服務器將 Connection 對象返回給應用程序 Java 應用程序，可以認為這個 Connection 對象是一個普通的 JDBC Connection 對象使用它可以和數據庫建立。事實上的連接與數據庫引擎產生交互操作。

9、當應用程序不需要使用 Connection 對象時，可以調用 Connection 接口的 close() 方法。請注意這種情況下 close() 方法并沒有關閉事實上的數據庫連接，僅僅是釋放了被應用程序占用的數據庫連接，并將它還給數據庫連接緩沖池，數據庫連接緩沖池會自動將這個數據庫連接交給請求隊列中下一個的應用程序使用。

現在，數據庫的連接沒有用到連接池幾乎很少很少，每個項目組都可能有自己的數據庫連接池組件，各容器提供商也提供了各自的數據庫連接池，下面介紹一下tomcat的數據庫連接管理。

tomcat6 數據源配置（server.xml方式和context.xml方式）

在server.xml下配置你必需重啟服務器才能生效，而context.xml配置保存后tomcat會自動加載無需重啟

在JNDI配配置數據源中需注意：項目下需要引入數據庫驅動包，并且TOMCAT下也需要引入，不然會報錯的

1.context.xml方式

Tomcat-6.0.26\conf\context.xml文件當添加以下的配置信息：

 其中：

name 表示指定的jndi名稱

auth 表示認證方式，一般為Container

type 表示數據源床型，使用標準的javax.sql.DataSource

maxActive 表示連接池當中最大的數據庫連接

maxIdle 表示最大的空閑連接數

maxWait 當池的數據庫連接已經被占用的時候，最大等待時間

logAbandoned 表示被丟棄的數據庫連接是否做記錄，以便跟蹤

username 表示數據庫用戶名

password 表示數據庫用戶的密碼

driverClassName 表示JDBC DRIVER

url 表示數據庫URL地址

注意，這里你配置的name值要和程序中使用的是一樣的，比如按照這個例子，程序就應該是這樣的，Java代碼：

關于獲取數據源的語法，大體有(javax.sql.DataSource) ctx.lookup("java:comp/env/XXX")和(javax.sql.DataSource)ctx.lookup("XXX")兩種寫法，好多人以為這兩種寫法是相同的，以為都是通過JNDI來獲取數據源。其實java:comp/env和 JNDI是不同的，java:comp/env 是環境命名上下文（environmentnaming context（ENC）），是在EJB規范1.1以后引入的，引入這個是為了解決原來JNDI查找所引起的沖突問題，也是為了提高EJB或者J2EE應用的移植性。ENC是一個引用，引用是用于定位企業應用程序的外部資源的邏輯名。引用是在應用程序部署描述符文件中定義的。在部署時，引用被綁定到目標可操作環境中資源的物理位置（JNDI名）。使用ENC是把對其它資源的JNDI查找的硬編碼解脫出來，通過配置這個引用可以在不修改代碼的情況下，將引用指向不同的EJB(JNDI)。

什么是JTA

Java Transaction API（Java事務API）(JTA)Java Transaction API(Application Programming Interface)

什么是JTA Transaction？它有怎樣的特點呢？JTA Transaction是指由J2EE Transaction manager去管理的事務。其最大的特點是調用UserTransaction接口的begin，commit和rollback方法來完成事務范圍的 界定，事務的提交和回滾。JTATransaction可以實現同一事務對應不同的數據庫，但是它仍然無法實現事務的嵌套。

分布式事務的規范由OMG的OTS所描述。

JTA是只是一組java接口用于描述，J2ee框架中事務管理器與應用程序，資源管理器，以及應用服務器之間的事務通訊。

它主要包括高層接口即面向應用程序的接口；XAResource接口即面向資源的接口；以及事務管理器的接口。值得注意的是JTA只提供了接口，沒有具體的實現。

JTS是服務OTS的JTA的實現。簡單的說JTS實現了JTA接口，并且符合OTS的規范。

資源管理器只要其提供給事務管理器的接口符合XA接口規范，就可以被事務管理器處理。 所以，JTA可以處理任何提供符合XA接口的資源。包括：數據庫，JMS，商業對象等等 

“Java 事務 API”（JTA）啟用兩階段提交功能。當配置WebSphere Application Server 以訪問數據庫時，可選擇具有 JTA 能力的驅動程序。如果需要兩階段提交功能，則必須使用啟用 JTA 的驅動程序。

只要您在事務中調用了多個數據庫連接，就需要 JTA。只要您在事務中調用了多個數據庫服務器，就需要兩階段提交。這些連接可以是相同的物理數據庫服務器或多個數據庫服務器。例如：

[list=1][*]實體企業 BeanEntity1 在應用程序服務器 AppServer1 中部署。[*]實體企業 Bean Entity2 在應用程序服務器AppServer1 中部署。[*]會話企業 Bean Session1 在應用程序服務器 AppServer1 中部署。[/list]如果Session1 對同一事務內的 Entity1 和 Entity2 調用了方法而這兩個企業 Bean 正在使用不同的物理數據庫連接，則必須對 Entity1 和 Entity2 使用的數據源啟用 JTA。當從相同的數據源對象獲取那些連接時，這也是成立的。這需要具有 JTA 能力的驅動程序以提交事務。
當事務涉及到多個進程時，JTA 也是必需的。例如，一個事務可能會涉及在多個應用程序服務器中部署的企業 Bean。
[list=1][*]實體企業 BeanEntity1 在應用程序服務器 AppServer1 中部署。[*]實體企業 Bean Entity2 在應用程序服務器AppServer2 中部署。[*]會話企業 Bean Session1 在應用程序服務器 AppServer1 中部署。[/list]如果Session1 對同一事務（此事務構成一個分布式事務）內的 Entity1 和 Entity2 調用了方法，則必須對 Entity1 和 Entity2 使用的數據源啟用 JTA。
性能實現JTA 啟用的連接與非 JTA 啟用的連接執行情況不同。基于此原因，如果您的應用程序不需要 JTA，則最好使用非 JTA 啟用的驅動程序。

其它信息有關 WebSphere Application Server 如何支持 JTA 的信息，參見 WebSphere Application Server 和 DB2UDB iSeries 版的事務處理及其子主題。

什么是JMS

jms即Java消息服務（JavaMessage Service）應用程序接口是一個Java平臺中關于面向消息中間件（MOM）的API，用于在兩個應用程序之間，或分布式系統中發送消息，進行異步通信。Java消息服務是一個與具體平臺無關的API，絕大多數MOM提供商都對JMS提供支持。jms同時也可以指Journal of Marketing Science，《營銷科學學報》的簡稱。此外，佳木斯的拼音縮寫也是jms。

傳遞方式

JMS有兩種傳遞消息的方式。標記為NON_PERSISTENT的消息最多投遞一次，而標記為PERSISTENT的消息將使用暫存后再轉送的機理投遞。如果一個JMS服務離線，那么持久性消息不會丟失但是得等到這個服務恢復聯機時才會被傳遞。所以默認的消息傳遞方式是非持久性的。即使使用非持久性消息可能降低內務和需要的存儲器，并且這種傳遞方式只有當你不需要接收所有的消息時才使用。

雖然JMS規范并不需要JMS供應商實現消息的優先級路線，但是它需要遞送加快的消息優先于普通級別的消息。JMS定義了從0到9的優先級路線級別，0是最低的優先級而9則是最高的。更特殊的是0到4是正常優先級的變化幅度，而5到9是加快的優先級的變化幅度。舉例來說： topicPublisher.publish (message, DeliveryMode.PERSISTENT, 8, 10000); //Pub-Sub 或 queueSender.send(message,DeliveryMode.PERSISTENT, 8, 10000);//P2P 　這個代碼片斷，有兩種消息模型，映射遞送方式是持久的，優先級為加快型，生存周期是10000 (以毫秒度量)。如果生存周期設置為零，這則消息將永遠不會過期。當消息需要時間限制否則將使其無效時，設置生存周期是有用的。

總結

本文關于JNDI,JTA和JMS簡介就到這里，希望對大家有所幫助。

原文鏈接：http://blog.csdn.net/cuiran/article/details/40950487