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的一些改进功能：

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一下就好了

这里的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 的承诺，而且经过一些计划和预先考虑，这个承诺是完全可以实现的。


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类型的数据库驱动


jdbc:oracle:thin:@192.168.6.100:1521:TestDB12


这里的JDBC正确的是部署到cluster上，而不是配置到代理服务器上，群里的哥说了，部署代理应用的时候，部署到代理节点，部署生产应用部署到其他的节点，（我的实验项目部署到代理）然后数据源目标是cluster里面的所有节点就可以了


sqlplus@hostname是sqlplus登录上来的会话，scott再用sqlplus登录两个会话之后变成如下。               

plsqldev.exe是plsql developer登录上来的，还是如果谁登录username就是谁

以上是“weblogic如何配置JDBC数据源”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注亿速云行业资讯频道！