weblogic如何配置JDBC數據源

發布時間：2021-12-07 11:27:20 來源：億速云閱讀：251 作者：小新欄目：編程語言

小編給大家分享一下weblogic如何配置JDBC數據源，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

weblogic如何配置JDBC數據源

一.概述

GridLink是WebLogic 10.3.4版本推出的新特性，引入Jdbc 11g version驅動，全面支持Oracle 11G RAC AWM的特性，包括我之前寫的SCAN新特性。

WebLogic被Oracle公司收購后，先是版本跟隨數據庫版本走，例如10.3.0命名為10g R2，10.3.1命名為11g R1，WebLogic越來越跟數據庫親密，我想是一家的東西要高度粘合，便是走上為企業應用提供成套的解決方案。WebLogic是J2EE企業級應用服務器，是J2EE應用跟DB之間的紐帶，進而為兩者提供高可用性的紐帶環境。Gridlink Data Source相對以前的Multi Data Source來說更有效率，因為它很大程度上借助了數據庫的功能。它使用了Oracle的ONS（Oracle Notification Service）的特征.

二.Link意在何處？
題目中的Link意為WebLogic連接DB的方式，這里的連接自然是JDBC Thin方式連接的，WebLogic是J2EE的容器，自身也是由Java語言編寫。
至今WebLogic提供了五種配置對于Jdbc Thin方式連接Oracle RAC，如下：
1.GridLink Data Sources
2.Configuring Connections to Services on Oracle RAC Nodes（XA）
3.Configuring Connections to Services on Oracle RAC Nodes（No-XA）
4.Multi Data Sources with Global Transactions
5.Multi Data Sources without Global Transactions
其中GridLink Data Sources方式支持使用services，實現Load Balancing（負載均衡）和Failover（故障轉移）。在Oracle Database 10g引入Automatic Workload Management，即數據庫服務，區別與傳統的數據庫服務。

三.GridLink的真面目
WLS GridLink是WLS10.3.4新推出的Data Source類型，提供了針對Oracle RAC數據庫與WLS之間的連接功能。GridLink通過Oracle通知服務（ONS）來獲取Oracle RAC實例的狀態變化。WLS可以通過Oracle RAC靈活的數據庫服務設計來滿足其需求，也可以由數據庫服務的增加而擴展而不需要關注RAC 集群中的物理結構變化。
連接示意圖如下：
GridLink提供了以下功能：
1.簡化和統一了對RAC連接配置的模塊。
2.支持Fast Connection Filover（FCF）。
3.支持Runtime Connection Load Balancing（RCLB）。
4.支持Single Client Access Name（SCAN）。
5.Oracle RAC停機的正常處理。
本篇文章為概述，此系列文章將對上面特性做一一分析和配置向導。

四.Oracle ONS（Oracle NOtification Service）和FAN（Fast Application Notification）
Oracle RAC通知服務（ONS）是由集群維護的，為nodeapps組。如：
查看ons服務狀態
$crsctl status resource ora.ons
AME=ora.ons
TYPE=ora.ons.type
TARGET=ONLINE , ONLINE
STATE=ONLINE on rac1, ONLINE on rac2
$srvctl status nodeapps
ONS daemon is running on node: gwrac1
ONS daemon is running on node: gwrac2
ONS服務，由srvctl工具來維護，另外onsctl工具也可以維護，還可以跟蹤ons的信息。下面是查看ons配置信息：
$srvctl config nodeapps -s
ONS daemon exists. Local port 6100, remote port 6200

Oracle RAC FAN為RAC applications和client提供集群狀態和節點負載的情況，通過ONS將這些事件發布給Java client和Oracle的客戶端，讓它們得知當前RAC的情況，做出相應的處理，例如：客戶端請求的分布。
基于以上的特性，Oracle稱其為高可用性、高可靠性、高可擴展性的，這個形容太響了。

Bea被Oracle收購以后，我們可以看到WebLogic和Oracle數據庫之間的更緊密結合。

剛剛合并以后推出的10gR3(10.3.0)版本中，原來Bea使用的Data Direct Driver被放棄，官方推薦使用Oracle的thin driver：
Note: The WebLogic Type 4 JDBC Oracle driver described in this document has been deprecated as of release 10.3 of WebLogic Server. It will be removed in the next release of WebLogic Server. Instead of this deprecated driver, use the Oracle Thin Driver that is also provided with WebLogic Server.

現在在WebLogic 10.3.4中，為了增強對RAC的支持，Oracle推出了Gridlink Data Source，取代原先的Multi Data Source：
http://download.oracle.com/docs/cd/E17904_01/web.1111/e13737/jdbc_intro.htm#BHCBACAG

Enhanced Oracle RAC Support
This release provides a new data source type, a GridLink Data Source, to provide enhanced support for Oracle RAC.
Multi Data Source

原來的Multi Data Source的工作原理是為每臺RAC的結點配置一個Datasource，然后把所有的這些Datasource聚合起來配置一個Multi Data Source。雖然Multi Data Source也提供Failover（容錯）和Load Balancing（負載均衡），但是功能相對有限。

1）配置比較復雜
需要為每一個RAC 結點手動配置一個Data Source，添加和刪除節點都需要WebLogic管理員手動操作。

2） Failover是data source級別的，不是connection 級別的
Multi Data Source需要開啟Test Reserved Connections (TestConnectionsOnReserve)功能。這個功能開啟以后，當應用向一個Data Source申請一個Connection的時候，WebLogic server需要先測試這個Connection再返回。如果這個測試失敗，WebLogic會重建一個連接。如果重建再失敗，Data Source就會被標識成dead，然后WebLogic自動Failover到下一個Multi Data Source里面的Data Source。當一個Data Source被標識成dead以后，WebLogic會主動的每隔一段時間（缺省120秒）查詢數據庫結點。如果測試成功，這個Data Source會被重新啟用。
對一個已經獲得并在使用的connection，WebLogic無法實現Failover。

3）Load Balancing僅僅是簡單的round robin
如果一個應用開啟了多個Connection，那么根據round robin的原則，這多個Connection可能會來自多個不同的數據庫結點。這個實際上有性能上的影響。
Gridlink Data Source
新推出的Gridlink Data Source相對來說更有效率，因為它很大程度上借助了數據庫的功能。它使用了Oracle的ONS（Oracle Notification Service）的特征。看下圖：
數據庫RAC端的ONS服務采集RAC結點的運行數據。這些數據傳給Gridlink Data Source的ONS監聽客戶端。UCP-RAC模塊分析這些數據并給出建議，Gridlink Data Source通過這些數據/建議來實現連接池的Failover，Load Balancing和其他的一些特性。

我們來看看Gridlink Data Source的一些改進功能：
weblogic如何配置JDBC數據源
1）首先，配置變得簡單了

你只需要配置一個Gridlink Data Source，它就會處理與后臺的RAC數據庫的通訊。相對Multi Data Source，WebLogic管理員的工作量減少很多。

如果你配置了Oracle的SCAN服務就更簡單了，RAC結點的添加刪除都是自動完成，因為對Gridlink Data Source來說，它只知道一個SCAN地址就好了。就好象一個域名一樣，你不需要知道后面用了多少IP來實現。

2）更快速有效的Failover
使用ONS，Gridlink Data Source可以實時的捕捉到RAC端的信息。如果有結點出錯，Gridlink Data Source很快將與其對應的Connection標識為不可用。這樣就避免了Multi Data Source中需要不斷主動測試Connection所帶來的overhead。

3）實時的Load Balancing
同樣因為ONS的數據，Gridlink Data Source可以知道哪些RAC結點很忙，哪些很閑，于是它可以有效的將哪些來自空閑RAC的Connection分配給應用請求，實現實時的Load Balancing。

4）沉穩應對RAC結點的關閉
如果是有計劃的關閉，Gridlink Data Source會等當前Active的事務結束再關閉Connection。新的Connection請求將被發送到其他的RAC結點。
如果是突發的RAC結點關閉，Gridlink Data Source也會沉著的將當前的事務rollback，然后將新的Connection請求發送到其他的RAC結點。

5）全局事務的Connectoin會盡量在一臺RAC結點上
前面講過Multi Data Source的Round Robin策略會造成同一個事務的多個Connection被發送到不同的RAC結點上。
Gridlink Data Source在一個事務的第一個Connection創建后會將該事務的所以后續Connection請求發送到同一個RAC結點上。這樣可以減少后臺同步處理，提高全局事務的運行效率。
創建Gridlink Data Source
創建的過程不復雜，和一個普通的Data Source差不多，都從這里開始：

1.名字之類的配置，注意數據庫類型就是Oracle，呵呵，當然了，RAC就是Oracle的：
2.XA的配置頁面掠過，到了輸入RAC地址的頁面
3.其實兩個選擇都一樣，一個是一個一個的添加server，然后由WebLogic生成JDBC URL：
一個是自己輸入JDBC URL：
沒有區別，怕寫錯就讓WebLogic生成，掠過測試頁面，下一步就是關鍵的ONS客戶端配置：
如果您使用SCAN的話，這里可以就輸入SCAN的地址。
Wallet可以用來加密ONS的通訊，這里不表。
掠過測試頁面，只要target一下就好了

weblogic如何配置JDBC數據源
這里的JNDI與web.xml中對應res-ref-name的節點值相同。
這里有必要說一下什么是JNDI

JNDI是 Java 命名與目錄接口（Java Naming and Directory Interface），在J2EE規范中是重要的規范之一，不少專家認為，沒有透徹理解JNDI的意義和作用，就沒有真正掌握J2EE特別是EJB的知識。
那么，JNDI到底起什么作用？
要了解JNDI的作用，我們可以從“如果不用JNDI我們怎樣做？用了JNDI后我們又將怎樣做？”這個問題來探討。
沒有JNDI的做法：
程序員開發時，知道要開發訪問MySQL數據庫的應用，于是將一個對 MySQL JDBC 驅動程序類的引用進行了編碼，并通過使用適當的 JDBC URL 連接到數據庫。
就像以下代碼這樣：
Connection conn=null;
try {
Class.forName("com.mysql.jdbc.Driver",
true, Thread.currentThread().getContextClassLoader());
conn=DriverManager.getConnection("jdbc:mysql://MyDBServer?user=qingfeng&password=mingyue");
/* 使用conn并進行SQL操作 */
......
conn.close();
}
catch(Exception e) {
e.printStackTrace();
}
finally {
if(conn!=null) {
try {
conn.close();
} 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-ds.xml 文件Copy到你使用的服務器下，如 D:/jboss420GA/server/default/deploy。
修改 mysql-ds.xml 文件的內容，使之能通過JDBC正確訪問你的MySQL數據庫，如下：
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<local-tx-datasource>
    <jndi-name>MySqlDS</jndi-name>
    <connection-url>jdbc:mysql://localhost:3306/lw</connection-url>
    <driver-class>com.mysql.jdbc.Driver</driver-class>
    <user-name>root</user-name>
    <password>rootpassword</password>
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name>
    <metadata>
       <type-mapping>mySQL</type-mapping>
    </metadata>
</local-tx-datasource>
</datasources>

這里，定義了一個名為MySqlDS的數據源，其參數包括JDBC的URL，驅動類名，用戶名及密碼等。

2、在程序中引用數據源：

Connection conn=null;
try {
  Context ctx=new InitialContext();
  Object datasourceRef=ctx.lookup("java:MySqlDS"); //引用數據源
  DataSource ds=(Datasource)datasourceRef;
  conn=ds.getConnection();
  /* 使用conn進行數據庫SQL操作 */
  ......
  c.close();
} 
catch(Exception e) {
  e.printStackTrace();
} 
finally {
  if(conn!=null) {
    try {
      conn.close(); } catch(SQLException e) { }
  }
}

直接使用JDBC或者通過JNDI引用數據源的編程代碼量相差無幾，但是現在的程序可以不用關心具體JDBC參數了。
在系統部署后，如果數據庫的相關參數變更，只需要重新配置 mysql-ds.xml 修改其中的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 的承諾，而且經過一些計劃和預先考慮，這個承諾是完全可以實現的。
weblogic如何配置JDBC數據源

oracle 驅動區別

oracle's driver thin
oracle's driver thin XA
oracle's (OCI XA)
oracle's (OCI)
weblogic's Oracle (Type 2 XA)
weblogic's Oracle (Type 2)
DataDirect's Oracle Driver (Type 4 XA)
DataDirect's Oracle Driver (Type 4)

這四類的區別是使用的驅動程序不一樣

第一個是thin驅動
第二個是普通的驅動，這都是Oracle自己提供的
第三個是weblogic提供的驅動
第四個是第三方驅動，由DataDirect提供

而每一種驅動可以配置兩種數據源
沒有XA的就是普通數據源
有XA的是支持JTA事務的數據源
創建連接池時，不帶事務的開發兩種驅動都可以選擇；帶事務的開發必須選擇XA類型的數據庫驅動

weblogic如何配置JDBC數據源
jdbc:oracle:thin:@192.168.6.100:1521:TestDB12

這里的JDBC正確的是部署到cluster上，而不是配置到代理服務器上，群里的哥說了，部署代理應用的時候，部署到代理節點，部署生產應用部署到其他的節點，（我的實驗項目部署到代理）然后數據源目標是cluster里面的所有節點就可以了

weblogic如何配置JDBC數據源
sqlplus@hostname是sqlplus登錄上來的會話，scott再用sqlplus登錄兩個會話之后變成如下。

plsqldev.exe是plsql developer登錄上來的，還是如果誰登錄username就是誰