Weblogic配置Oracle数据源.docx

上传人:b****5 文档编号:5383198 上传时间:2022-12-15 格式:DOCX 页数:28 大小:37.87KB
下载 相关 举报
Weblogic配置Oracle数据源.docx_第1页
第1页 / 共28页
Weblogic配置Oracle数据源.docx_第2页
第2页 / 共28页
Weblogic配置Oracle数据源.docx_第3页
第3页 / 共28页
Weblogic配置Oracle数据源.docx_第4页
第4页 / 共28页
Weblogic配置Oracle数据源.docx_第5页
第5页 / 共28页
点击查看更多>>
下载资源
资源描述

Weblogic配置Oracle数据源.docx

《Weblogic配置Oracle数据源.docx》由会员分享,可在线阅读,更多相关《Weblogic配置Oracle数据源.docx(28页珍藏版)》请在冰豆网上搜索。

Weblogic配置Oracle数据源.docx

Weblogic配置Oracle数据源

配置和管理WebLogicJDBC

配置JDBC数据源

本部分包括以下信息:

∙了解JDBC数据源

∙创建JDBC数据源

∙事务选项

∙连接缓冲池功能

∙设置数据库安全凭据

∙调整数据源连接缓冲池选项

∙在服务器和群集上部署数据源

∙最大程度地减少由不响应的数据库引起的服务器启动暂停

∙JDBC数据源的安全

∙JDBC数据源工厂(不赞成使用)

 

了解JDBC数据源

在WebLogicServer中,可通过将数据源添加到您的WebLogic域来配置数据库连接。

WebLogicJDBC数据源提供了数据库访问和数据库连接管理。

每个数据源都包含一个数据库连接缓冲池,其中的数据库连接是在创建数据源时和启动服务器时创建的。

应用程序会通过在JNDI树中或在本地应用程序上下文中查找数据源,然后调用getConnection()来保留来自数据源的数据库连接。

完成连接后,应用程序应尽早调用connection.close(),该方法会将数据库连接返回缓冲池以供其他应用程序使用。

数据源及其连接缓冲池可以提供有助于保持系统运行和性能的连接管理进程。

可以设置数据源中的选项以满足您的应用程序和您的环境的需要。

以下部分描述了这些选项以及如何启用这些选项。

 

创建JDBC数据源

要在您的WebLogic域中创建JDBC数据源,可以使用管理控制台或WebLogic脚本工具(WLST)。

有关详细信息,请参阅以下部分:

∙"“管理控制台联机帮助”中的创建JDBC数据源

∙"“WebLogic脚本工具”中的创建JDBC资源

注意:

WLST已取代了weblogic.Admin命令行实用工具。

WebLogicServer示例(可选择将其随WebLogicServer一起安装)包含了可用来代替weblogic.AdminJDBC命令的示例脚本。

如果已安装了上述示例,则这些示例脚本可从WL_HOME\samples\server\examples\src\examples\wlst\online获得,其中,WL_HOME指WebLogic主目录,如C:

\bea\weblogic91。

有关JDBC数据源特性的详细信息,请参阅“WebLogicServerMBeanReference”中的JDBCDataSourceBean及其所有子Mbean。

∙“管理控制台联机帮助”中的JDBC数据源参考页:

oJDBC数据源:

配置:

常规

oJDBC数据源:

配置:

连接缓冲池

oJDBC数据源:

配置:

事务

oJDBC数据源:

配置:

诊断

oJDBC数据源:

配置:

标识选项

oJDBC数据源:

目标

oJDBC数据源:

安全:

角色

oJDBC数据源:

安全:

策略

oJDBC数据源:

安全:

凭据映射

注意:

管理控制台中的“创建JDBC数据源”页中列出的JDBC驱动程序不必经过认证,即可用于WebLogicServer。

与“创建JDBC数据源”页的目标一致,列出JDBC驱动程序的目的是为了便于帮助您创建与多数可用数据库管理系统的连接。

注意:

要使用JDBC驱动程序在每个服务器(已在该服务器上部署了数据源)上的数据源中创建数据库连接,必须安装JDBC驱动程序。

管理控制台中的“创建JDBC数据源”页中列出了驱动程序及其已知的必需配置选项,以帮助您配置数据源。

该列表中的JDBC驱动程序不是必须安装的。

驱动程序安装可包括设置系统路径、类路径以及其他环境变量。

请参阅针对Type-4第三方JDBC驱动程序设置环境。

注意:

更新了JDBC驱动程序之后,配置要求可能会更改。

管理控制台中的“创建JDBC数据源”页采用发布WebLogicServer软件时已知的配置要求。

如果您的JDBC驱动程序的配置选项已更改,那么,您可能需要在创建数据源时手工替换这些配置选项,或在创建数据源之后,在该数据源的属性页中手工替换这些配置选项。

常规数据源选项

JDBC数据源包括一些选项,这些选项可用于确定数据源的标识、在数据库连接上处理数据的方式和在全局事务中使用来自数据源的某个连接时处理事务的方式。

可以在管理控制台中的JDBC数据源:

配置:

常规页上查看某个JDBC数据源的常规选项。

还可以从JDBCDataSourceBean的子级JDBCDataSourceParamsBean访问这些选项。

选择JDBC驱动程序

在决定要使用哪一个JDBC驱动程序来连接到数据库时,应在环境中尝试来自多个供应商的驱动程序。

一般而言,JDBC驱动程序的性能取决于多种因素,尤其是应用程序中使用的SQL代码和JDBC驱动程序的实现。

有关受支持的JDBC驱动程序的详细信息,请参阅“SupportedConfigurationsforWebLogicPlatform9.2”中的SupportedDatabaseConfigurations。

JDBC数据源名称

JDBC数据源名称用于标识WebLogic域中的数据源。

对于系统资源数据源,其名称在所有其他JDBC系统资源(包括数据源和多数据源)中必须唯一。

为了避免命名冲突,数据源名称在其他配置对象(如服务器、群集以及JMS队列、主题及服务器)名称中也应当是唯一的。

对于作用于某个应用程序的JDBC应用程序模块,数据源名称在作用于相似范围的JDBC数据源和多数据源中必须唯一。

使用多个名称将某个数据源绑定到JNDI树

在WebLogicServer9.0和更高版本中,可配置一个数据源,以便使用多个名称将其绑定到JNDI树。

可使用多JNDI名称的数据源替换一些旧式配置(这些旧式配置包括了指向单个JDBC连接缓冲池的多个数据源)。

要使用管理控制台将JNDI名称添加到现有的数据源,请将名称添加到“JNDI名称”特性中(每个JNDI名称都位于单独的一行)。

必须在做出更改之后重新启动系统,或者在做出更改之前取消部署数据源,然后在做出更改之后重新进行部署。

请按照以下说明进行操作。

1.在“常规”页(可通过在管理控制台中依次选择“JDBC数据源”

“配置”

“常规”页来访问该页)上的“JNDI名称”中,输入要用于将数据源绑定到JDNI树的名称(每个名称位于单独的一行)。

例如:

name1

name2

name3

2.单击“保存”。

激活更改之后,要使更改生效,需要重新部署数据源或重新启动服务器。

 

事务选项

使用管理控制台配置JDBC数据源时,WebLogicServer会根据JDBC驱动程序的类型自动选择特定的事务选项:

∙对于XA驱动程序,系统会自动选择用于全局事务处理的两阶段提交协议。

∙对于非XA驱动程序,将按照定义支持本地事务,并且WebLogicServer会提供以下选项

支持全局事务:

(在默认情况下处于选中状态)如果要在全局事务中使用来自数据源的连接,则选中此选项,即使未选择XA驱动程序也是如此。

有关详细信息,请参阅使用非XAJDBC驱动程序启用对全局事务的支持。

选中“支持全局事务”时,还必须为WebLogicServer选择在处理全局事务时要用于事务分支的协议:

o记录上一个资源:

使用此选项,会将使用连接的事务分支作为事务中最后的资源进行处理,并将其作为本地事务进行处理。

两阶段提交(two-phasecommit,简称2PC)的提交记录会插入资源自身的表中,且此结果确定了全局事务准备阶段的成功或失败。

与“仿真两阶段提交”相比,此选项具有一些性能优势和更高的数据安全性,但它具有某些限制。

请参阅了解“记录上一个资源”选项。

注意:

多数据源使用的数据源不支持“记录上一个资源”。

o仿真两阶段提交:

使用此选项,使用连接的事务分支始终返回事务准备阶段的成功信息。

此选项提供了性能优势,但在某些失败情况下也存在破坏数据的风险。

只有在应用程序可允许出现试探性情况时才能选择此选项。

请参阅了解“仿真两阶段提交”事务选项。

o一阶段提交:

(在默认情况下处于选中状态)使用此选项,来自数据源的连接只能是全局事务的唯一参与者,并且该事务是使用一阶段提交优化完成的。

如果多个资源参与该事务,则事务管理器在1PC资源上调用XAResource.prepare时会引发异常。

使用非XAJDBC驱动程序启用对全局事务的支持

如果在应用程序中使用全局事务,则应使用XAJDBC驱动程序在JDBC数据源中创建数据库连接。

如果某个XA驱动程序不可用于您的数据库,或者您不希望使用XA驱动程序,那么您应在数据源中启用对全局事务的支持。

如果应用程序满足以下任何一个条件,则也应启用对全局事务的支持:

∙使用WebLogicServer中的EJB容器来管理事务

∙在一个事务中包括多个数据库更新

∙在一个事务中访问多个资源(如数据库和Java消息服务(JMS))

∙在多个服务器(群集或非群集)上使用相同的数据源

使用EJB体系结构时,将多个进行数据库工作的EJB作为单个事务的一部分进行调用是很常见的。

如果不使用XA,那么,要实现上述功能,唯一的途径就是所有的事务参与者都使用完全相同的数据库连接。

在启用了全局事务并选择了“记录上一个资源”或“仿真两阶段提交”后,WebLogicServer会在内部使用JTS驱动程序以确保所有EJB都在同一事务上下文中使用同一数据库连接,而无需您将连接从EJB显式传递到EJB。

如果多个EJB正在参与某个事务,并且您未将XAJDBC驱动程序用于数据库连接,则请使用以下选项配置数据源:

∙选中“支持全局事务”

∙选中“记录上一个资源”或“仿真两阶段提交”

此配置将强制JTS驱动程序在内部将同一数据库连接用于同一事务中的所有数据库工作。

使用XA(要求使用XA驱动程序)时,EJB可针对事务的每个部分使用不同的数据库连接。

WebLogicServer会使用两阶段提交协议来协调事务,该协议可保证会完成该事务的全部或不完成该事务的任何部分。

了解“记录上一个资源”选项

WebLogicServer通过JDBC数据源支持“记录上一个资源”(LoggingLastResource,简称LLR)事务优化。

LLR是一个性能增强选项,使用该选项可使一个非XA资源能够使用与XA同样的ACID保证参与全局事务。

LLR是“上一个代理优化”的改进结果。

它与“上一个代理优化”不同,因为它对于事务而言是安全的。

LLR资源对其事务工作使用本地事务。

WebLogicServer事务管理器准备事务中的所有其他资源,然后根据LLR资源本地事务的结果确定全局事务的提交决定。

LLR优化通过以下方式提高性能:

∙免除了使用XAJDBC驱动程序连接到数据库的需求。

与非XAJDBC驱动程序相比,XAJDBC驱动程序通常较为低效。

∙减少了完成事务时所需的处理步骤,这也减少了网络流量和磁盘I/O次数。

∙免除了在数据库级别进行XA处理的需求

当为LLR配置的数据源中的连接参与两阶段提交(2PC)全局事务时,WebLogicServer事务管理器会通过以下方式完成事务:

∙在所有其他(符合XA标准的)事务参与者上调用准备。

∙将一个提交记录插入LLR参与者的表中(而不是基于文件的事务日志中)。

∙提交LLR参与者的本地事务(包括事务提交记录插入和该应用程序的SQL工作)。

∙在所有其他事务参与者上调用提交。

对于一阶段提交(one-phasecommit,简称1PC),LLR可通过使用本地事务完成数据库操作来消除XA开销,但任何2PC事务记录都不会写入数据库。

“记录上一个资源”优化可通过在LLR参与者上写入提交记录来保持数据完整性。

如果事务在本地事务提交期间失败,则WebLogicServer事务管理器会在所有其他事务参与者上回滚该事务。

对于失败恢复,WebLogicServer事务处理器会读取LLR资源上的事务日志以及默认存储中的其他事务日志文件,然后根据需要完成任何事务处理。

如果存在某个提交记录,则会提交与XA参与者相关联的工作,否则会回滚其工作。

有关如何创建一个启用LLR的JDBC数据源的说明,请参阅“管理控制台联机帮助”中的创建启用了LLR的JDBC数据源。

有关“记录上一个资源”事务处理的详细信息,请参阅“WebLogicJTA编程”中的“记录上一个资源”事务优化。

使用“记录上一个资源”的优势

由于LLR协议具有性能优势,因此您可能需要考虑使用LLR事务协议替换用于事务处理的两阶段提交协议,具体取决于您的环境。

LLR事务协议具有以下优势:

∙允许非XAJDBC驱动程序和甚至没有XA功能的数据库安全地参与两阶段提交事务。

∙无需数据库使用XA协议。

∙其性能优于JDBCXA连接。

∙减少了持有数据库行锁定的时间。

∙始终在提交其他XA工作之前提交数据库工作。

在XA事务中,这些操作是并行提交的,因此,例如,当某个JMS发送参与该事务时,JMS消息可能会在数据库工作提交之前进行传递。

使用LLR时,会在完成所有其他事务工作之前完成本地事务中的数据库工作。

∙与JDBC数据源的“仿真两阶段提交”选项不同,不会增加试探性威胁的风险。

注意:

LLR优化使插入、更新和删除操作的性能得到了显著提高。

但是,对于使用LLR时的读操作,其性能会比使用XA时的读操作稍有降低。

为了获得最佳性能,可能需要对只读操作配置非LLRJDBC数据源。

注意:

有关使用LLR时的性能调整的详细信息,请参阅“WebLogicJTA编程”中的使用LLR优化性能。

启用“记录上一个资源”事务优化

为了启用LLR事务优化,您要使用“记录上一个资源”事务协议创建一个JDBC数据源,然后在您的应用程序中使用来自该数据源的数据库连接。

WebLogicServer会在数据库中自动创建所需的表。

请参阅“管理控制台联机帮助”中的创建启用了LLR的JDBC数据源。

LLR数据源的编程注意事项和限制

可按照使用来自任何其他数据源的JDBC连接的方式,在应用程序中使用来自启用了LLR的数据源的JDBC连接:

在开始某个事务之后,在JNDI树中查找数据源,然后请求一个来自该数据源的连接。

但是,使用LLR优化时,WebLogicServer会在内部管理连接请求,并以不同于在XA事务中使用的处理方式来处理事务处理。

有关“记录上一个资源”的工作方式的详细信息,请参阅“WebLogicJTA编程”中的“记录上一个资源”事务优化。

请注意以下内容:

∙使用LLR数据源进行编程时,必须在调用LLR数据源的getConnection之前启动全局事务。

如果在启动全局事务之前调用getConnection,则会使对该连接的所有操作都处于全局事务之外。

∙仅对每个事务保留一个内部JDBCLLR连接,并且该连接将用于整个事务处理。

∙保留的连接始终承载在该事务的协调器服务器上。

请确保该数据源已定位到协调服务器或群集。

另请参阅“WebLogicJTA编程”中的使用LLR优化性能。

∙对于该事务中来自同名数据源的其他JDBC连接请求,操作会路由到来自原始连接请求的已保留连接,即使后续请求是在该数据源的其他实例(即部署在与为第一个请求提供连接的原始数据源所在服务器不同的服务器上的数据源)上做出的,也是如此。

请注意以下内容:

o在功能和性能方面,路由的LLR连接可能不如本地承载的XA连接。

(请参阅在多服务器配置中使用非XA资源时可能产生的性能损失。

o连接请求路由会限制并发事务的个数。

最大并发LLR事务数等于协调器的JDBCLLR数据源的已配置大小(MaxCapacity)。

o路由连接的功能少于本地连接的功能,可能会因此而导致失败。

具体地说,在查询ResultSet中的非序列化“自定义”数据类型可能会失败。

∙只有单个LLR数据源的实例可以参与某个特定事务。

单个LLR数据源可在多个WebLogic服务器上具有实例,如果两个数据源具有相同的已配置名称,则这两个数据源会被认为是相同的。

如果检测到多个LLR数据源实例,并且它们不是同一数据源的实例,则事务管理器会回滚事务。

∙实现weblogic.transaction.nonxa.NonXAResource接口的资源适配器(连接器)不能参与LLR资源也同时参与的全局事务,因为二者都必须是事务中的最后一个资源。

如果两种资源类型都参与同一个事务,则在检测到此冲突时,事务的commit()方法会引发javax.transaction.RollbackException。

∙由于LLR连接对于数据库处理使用单独的本地事务,因此,在LLR处理过程中,使用XA连接对同一数据库进行的任何更改(和进行的任何锁定)都将不可见,即使所有的处理都发生在同一全局事务中,也是如此。

在某些情况下,这可能会在数据库中引起死锁。

在单个全局事务中不应在同一数据库中混合XA和LLR处理。

∙来自某个LLR数据源的连接不能参与由外部事务管理器协调的事务,如由远程对象请求代理或由Tuxedo启动的事务。

∙全局事务不能跨至另一个包含了与某个LLR数据源同名的数据源的旧式域。

∙对于JDBCLLR2PC事务,如果事务数据太大,无法装入LLR表中,则事务将会失败,并在提交期间生成一个回滚异常。

如果在事务处理过程中,您的应用程序添加了许多事务属性,则会发生上述情况。

(请参阅JTA的BEAWebLogic扩展。

)如果发生了上述情况,那么,数据库管理员可手工创建一个具有更大的列的表。

LLR数据源的管理注意事项和限制

配置启用了LLR的JDBC数据源时,请考虑以下要求和限制:

有关“记录上一个资源”的工作方式的详细信息,请参阅“WebLogicJTA编程”中的“记录上一个资源”事务优化。

∙对于每个服务器,都有一个LLR表:

o多个LLR数据源可共享一个表。

o如果找不到该表,则WebLogicServer会自动创建该表。

o默认名称为WL_LLR_SERVERNAME。

可在管理控制台中,依次选择服务器>配置>常规选项卡,在该选项卡上的“高级”选项下配置该表名。

∙如果在引导期间数据库处于关闭状态或LLR表不可访问,则服务器将不会进行引导。

∙多个服务器不得共享同一个LLR表。

引导会进行检查,以确保域和服务器名称与创建表时存储在表中的域和服务器名称相匹配。

如果WebLogicServer检测到多个服务器正在共享同一个LLR表,则WebLogicServer将关闭一个或多个服务器。

∙LLR支持服务器迁移和事务恢复服务迁移。

要使用事务恢复服务迁移,请确保每个LLR资源都会定位到群集或群集中的候选服务器组。

请参阅“为发生故障的群集服务器恢复事务”。

∙在JDBC应用程序模块中不允许使用LLR事务选项。

∙多数据源使用的数据源中不支持使用LLR事务选项。

∙如果在某个LLR数据源上使用了凭据映射,则所有映射的用户都必须具有对该LLR表的写权限。

∙不能使用JDBCXA驱动程序在JDBCLLR数据源中创建数据库连接。

如果JDBCLLR数据源中使用的JDBC驱动程序支持XA,则会记录一条警告消息,并且数据源会作为完全的XA资源(而不是作为LLR资源)参与事务。

∙会在“NonXAResource”下跟踪LLR资源的事务统计信息。

请参阅“管理控制台联机帮助”中的查看非XA资源的事务统计信息。

了解“仿真两阶段提交”事务选项

如果需要使用某个JDBC数据源来支持分布式事务,但没有符合XA标准的驱动程序可供您的DBMS使用,则可对某个数据源的“非XA驱动程序”选项选择“仿真两阶段提交”,以便对来自该数据源的连接参与的事务仿真两阶段提交。

此选项是“常规”选项卡(可通过依次选择“JDBC数据源”

“配置”

“常规”选项卡来访问该选项卡)上的高级选项。

对“非XA驱动程序”选项选择“仿真两阶段提交”(EnableTwoPhaseCommit设置为true)时,非XAJDBC资源总是会在XAResource.prepare()方法调用期间返回XA_OK。

资源会尝试提交或回滚其本地事务以响应后续的XARmit()或XAResource.rollback()调用。

如果资源提交或回滚失败,则会导致一个试探性错误。

应用程序数据可能会由于试探性失败而处于不一致状态。

未在控制台中对“非XA驱动程序”选项选择“仿真两阶段提交”(EnableTwoPhaseCommit设置为false)时,非XAJDBC资源会导致XAResource.prepare()失败。

当仅有一个资源参与事务时,一阶段优化将跳过XAResource.prepare(),并且在大多数情况下,事务会成功提交。

注意:

对“非XA驱动程序”选项选择“仿真两阶段提交”时,会存在破坏数据完整性的风险。

BEA建议使用符合XA标准的JDBC驱动程序或“记录上一个资源”选项(而不是使用“仿真两阶段提交”选项)。

请确保在启用此选项之前考虑了这些风险。

该非XAJDBC驱动程序支持通常称为“JTS驱动程序”,因为WebLogicServer在内部使用WebLogicJTS驱动程序以支持该功能。

有关WebLogicJTS驱动程序的详细信息,请参阅“WebLogicJDBC编程”中的使用WebLogicJTS驱动程序。

使用非XA驱动程序仿真两阶段提交时的限制和风险

WebLogicServer使用“仿真两阶段提交”数据源事务选项支持非XAJDBC资源参与全局事务,但会存在一些在设计应用程序(以使用这样的数据源)时必须考虑的限制。

因为非XA驱动程序不符合XA/2PC合同,并且仅支持一阶段提交和回滚操作,所以WebLogicServer(通过JTS驱动程序)必须进行妥协以允许资源参与由事务管理器控制的某个事务。

在对“非XA驱动程序”选项使用“仿真两阶段提交”之前,请考虑以下限制和风险:

试探性完成和数据不一致

对非XA资源选择“仿真两阶段提交”(enableTwoPhaseCommit=true)时,非XA资源的事务准备阶段总是会成功。

因此,非XA资源没有真正地参与两阶段提交(2PC)协议

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高等教育 > 其它

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1