weblogic DataSource 配置注意事项 .

weblogic 建立datasource时，配置注意事项，记录一下weblogic 的doc。

事务选项

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

• 对于 XA 驱动程序，系统会自动选择用于全局事务处理的两阶段提交协议。
• 对于非 XA 驱动程序，将按照定义支持本地事务，而且 WebLogic Server 会提供如下选项

  支持全局事务：（在默认状况下处于选中状态）若是要在全局事务中使用来自数据源的链接，则选中此选项，即便未选择 XA 驱动程序也是如此。有关详细信息，请参阅使用非 XA JDBC 驱动程序启用对全局事务的支持。

  选中“支持全局事务”时，还必须为 WebLogic Server 选择在处理全局事务时要用于事务分支的协议：

  • 记录上一个资源：使用此选项，会将使用链接的事务分支做为事务中最后的资源进行处理，并将其做为本地事务进行处理。两阶段提交（two-phase commit，简称 2PC）的提交记录会插入资源自身的表中，且此结果肯定了全局事务准备阶段的成功或失败。与“仿真两阶段提交”相比，此选项具备一些性能优点和更高的数据安全性，但它具备某些限制。请参阅了解“记录上一个资源”选项。

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

  • 仿真两阶段提交：使用此选项，使用链接的事务分支始终返回事务准备阶段的成功信息。此选项提供了性能优点，但在某些失败状况下也存在破坏数据的风险。只有在应用程序可容许出现试探性状况时才能选择此选项。
  • 一阶段提交：（在默认状况下处于选中状态）使用此选项，来自数据源的链接只能是全局事务的惟一参与者，而且该事务是使用一阶段提交优化完成的。若是多个资源参与该事务，则事务管理器在 1PC 资源上调用XAResource.prepare时会引起异常。

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

若是在应用程序中使用全局事务，则应使用 XA JDBC 驱动程序在 JDBC 数据源中建立数据库链接。若是某个 XA 驱动程序不可用于您的数据库，或者您不但愿使用 XA 驱动程序，那么您应在数据源中启用对全局事务的支持。若是应用程序知足如下任何一个条件，则也应启用对全局事务的支持：

• 使用 WebLogic Server 中的 EJB 容器来管理事务
• 在一个事务中包括多个数据库更新
• 在一个事务中访问多个资源（如数据库和 Java 消息服务 (JMS)）
• 在多个服务器（群集或非群集）上使用相同的数据源

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

WebLogic Server 经过 JDBC 数据源支持“记录上一个资源”（Logging Last Resource，简称 LLR）事务优化。LLR 是一个性能加强选项，使用该选项可以使一个非 XA 资源可以使用与 XA 一样的 ACID 保证参与全局事务。LLR 是“上一个代理优化”的改进结果。它与“上一个代理优化”不一样，由于它对于事务而言是安全的。LLR 资源对其事务工做使用本地事务。WebLogic Server 事务管理器准备事务中的全部其余资源，而后根据 LLR 资源本地事务的结果肯定全局事务的提交决定。

LLR 优化经过如下方式提升性能：

• 免除了使用 XA JDBC 驱动程序链接到数据库的需求。与非 XA JDBC 驱动程序相比，XA JDBC 驱动程序一般较为低效。
• 减小了完成事务时所需的处理步骤，这也减小了网络流量和磁盘 I/O 次数。
• 免除了在数据库级别进行 XA 处理的需求

当为 LLR 配置的数据源中的链接参与两阶段提交 (2PC) 全局事务时，WebLogic Server 事务管理器会经过如下方式完成事务：

• 在全部其余（符合 XA 标准的）事务参与者上调用准备。
• 将一个提交记录插入 LLR 参与者的表中（而不是基于文件的事务日志中）。
• 提交 LLR 参与者的本地事务（包括事务提交记录插入和该应用程序的 SQL 工做）。
• 在全部其余事务参与者上调用提交。

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

可按照使用来自任何其余数据源的 JDBC 链接的方式，在应用程序中使用来自启用了 LLR 的数据源的 JDBC 链接：在开始某个事务以后，在 JNDI 树中查找数据源，而后请求一个来自该数据源的链接。可是，使用 LLR 优化时，WebLogic Server 会在内部管理链接请求，并以不一样于在 XA 事务中使用的处理方式来处理事务处理。

请注意如下事项：

• 使用 LLR 数据源进行编程时，必须在调用 LLR 数据源的 getConnection 以前启动全局事务。若是在启动全局事务以前调用 getConnection，则会使对该链接的全部操做都处于全局事务以外。
• 仅对每一个事务保留一个内部 JDBC LLR 链接，而且该链接将用于整个事务处理。
• 保留的链接始终承载在该事务的协调器服务器上。请确保该数据源已定位到协调服务器或群集。
• 对于该事务中来自同名数据源的其余 JDBC 链接请求，操做会路由到来自原始链接请求的已保留链接，即便后续请求是在该数据源的其余实例（即部署在与为第一个请求提供链接的原始数据源所在服务器不一样的服务器上的数据源）上作出的，也是如此。请注意如下内容：
  • 在功能和性能方面，路由的 LLR 链接可能不如本地承载的 XA 链接。
  • 链接请求路由会限制并发事务的个数。最大并发 LLR 事务数等于协调器的 JDBC LLR 数据源的已配置大小 (MaxCapacity)。
  • 路由链接的功能少于本地链接的功能，可能会所以而致使失败。具体地说，在查询 ResultSet 中的非序列化“自定义”数据类型可能会失败。
• 只有单个 LLR 数据源的实例能够参与某个特定事务。单个 LLR 数据源可在多个 WebLogic 服务器上具备实例，若是两个数据源具备相同的已配置名称，则这两个数据源会被认为是相同的。若是检测到多个 LLR 数据源实例，而且它们不是同一数据源的实例，则事务管理器会回滚事务。
• 实现weblogic.transaction.nonxa.NonXAResource接口的资源适配器（链接器）不能参与 LLR 资源也同时参与的全局事务，由于两者都必须是事务中的最后一个资源。若是两种资源类型都参与同一个事务，则在检测到此冲突时，事务的commit()方法会引起javax.transaction.RollbackException。
• 因为 LLR 链接对于数据库处理使用单独的本地事务，所以，在 LLR 处理过程当中，使用 XA 链接对同一数据库进行的任何更改（和进行的任何锁定）都将不可见，即便全部的处理都发生在同一全局事务中，也是如此。在某些状况下，这可能会在数据库中引发死锁。在单个全局事务中不该在同一数据库中混合 XA 和 LLR 处理。
• 来自某个 LLR 数据源的链接不能参与由外部事务管理器协调的事务，如由远程对象请求代理或由 Tuxedo 启动的事务。
• 全局事务不能跨至另外一个包含了与某个 LLR 数据源同名的数据源的旧式域。
• 对于 JDBC LLR 2PC 事务，若是事务数据太大，没法装入 LLR 表中，则事务将会失败，并在提交期间生成一个回滚异常。若是在事务处理过程当中，您的应用程序添加了许多事务属性，则会发生上述状况。若是发生了上述状况，那么，数据库管理员可手工建立一个具备更大的列的表。

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

配置启用了 LLR 的 JDBC 数据源时，请考虑如下要求和限制：

• 对于每一个服务器，都有一个 LLR 表：
  • 多个 LLR 数据源可共享一个表。
  • 若是找不到该表，则 WebLogic Server 会自动建立该表。
  • 默认名称为WL_LLR_SERVERNAME。可在管理控制台中，依次选择服务器 > 配置 > 常规选项卡，在该选项卡上的“高级”选项下配置该表名。
• 若是在引导期间数据库处于关闭状态或 LLR 表不可访问，则服务器将不会进行引导。
• 多个服务器不得共享同一个 LLR 表。引导会进行检查，以确保域和服务器名称与建立表时存储在表中的域和服务器名称相匹配。若是 WebLogic Server 检测到多个服务器正在共享同一个 LLR 表，则 WebLogic Server 将关闭一个或多个服务器。
• LLR 支持服务器迁移和事务恢复服务迁移。要使用事务恢复服务迁移，请确保每一个 LLR 资源都会定位到群集或群集中的候选服务器组。请参阅“为发生故障的群集服务器恢复事务”。
• 在 JDBC 应用程序模块中不容许使用 LLR 事务选项。
• 多数据源使用的数据源中不支持使用 LLR 事务选项。
• 若是在某个 LLR 数据源上使用了凭据映射，则全部映射的用户都必须具备对该 LLR 表的写权限。
• 不能使用 JDBC XA 驱动程序在 JDBC LLR 数据源中建立数据库链接。若是 JDBC LLR 数据源中使用的 JDBC 驱动程序支持 XA，则会记录一条警告消息，而且数据源会做为彻底的 XA 资源（而不是做为 LLR 资源）参与事务。
• 会在“NonXAResource”下跟踪 LLR 资源的事务统计信息。

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

若是须要使用某个 JDBC 数据源来支持分布式事务，但没有符合 XA 标准的驱动程序可供您的 DBMS 使用，则可对某个数据源的“非 XA 驱动程序”选项选择“仿真两阶段提交”，以便对来自该数据源的链接参与的事务仿真两阶段提交。此选项是“常规”选项卡（可经过依次选择“JDBC 数据源”“配置”“常规”选项卡来访问该选项卡）上的高级选项。

对“非 XA 驱动程序”选项选择“仿真两阶段提交”（EnableTwoPhaseCommit设置为true）时，非 XA JDBC 资源老是会在XAResource.prepare() 方法调用期间返回XA_OK。资源会尝试提交或回滚其本地事务以响应后续的XAResource.commit() 或XAResource.rollback() 调用。若是资源提交或回滚失败，则会致使一个试探性错误。应用程序数据可能会因为试探性失败而处于不一致状态。

未在控制台中对“非 XA 驱动程序”选项选择“仿真两阶段提交”（EnableTwoPhaseCommit设置为false）时，非 XA JDBC 资源会致使XAResource.prepare() 失败。当仅有一个资源参与事务时，一阶段优化将跳过XAResource.prepare()，而且在大多数状况下，事务会成功提交。

注意：	对“非 XA 驱动程序”选项选择“仿真两阶段提交”时，会存在破坏数据完整性的风险。BEA 建议使用符合 XA 标准的 JDBC 驱动程序或“记录上一个资源”选项（而不是使用“仿真两阶段提交”选项）。请确保在启用此选项以前考虑了这些风险。

该非 XA JDBC 驱动程序支持一般称为“JTS 驱动程序”，由于 WebLogic Server 在内部使用 WebLogic JTS 驱动程序以支持该功能。

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

WebLogic Server 使用“仿真两阶段提交”数据源事务选项支持非 XA JDBC 资源参与全局事务，但会存在一些在设计应用程序（以使用这样的数据源）时必须考虑的限制。由于非 XA 驱动程序不符合 XA/2PC 合同，而且仅支持一阶段提交和回滚操做，因此 WebLogic Server（经过 JTS 驱动程序）必须进行妥协以容许资源参与由事务管理器控制的某个事务。

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

试探性完成和数据不一致

对非 XA 资源选择“仿真两阶段提交”(enableTwoPhaseCommit = true) 时，非 XA 资源的事务准备阶段老是会成功。所以，非 XA 资源没有真正地参与两阶段提交 (2PC) 协议，而且容易失败。若是在准备阶段以后，在非 XA 资源中发生故障，则非 XA 资源可能会在 XA 事务参与者要提交事务时回滚事务，从而致使试探性完成和数据不一致。

因为存在破坏数据完整性的风险，因此，“仿真两阶段提交”选项仅应在可容许出现试探性状况的应用程序中使用。

没法恢复待定事务

由于非 XA 驱动程序仅对本地数据库事务进行操做，因此，在有关外部事务管理器的数据库中没有事务待定状态的概念。在非 XA 资源上调用XAResource.recover()时，该方法老是会返回 Xid（事务 ID）的一个空集，即便可能有须要提交或回滚的事务，也是如此。所以，那些在全局事务中使用非 XA 资源的应用程序没法从系统故障中恢复过来，并没有法保持数据完整性。

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

由于 WebLogic Server 依赖于与特定 JDBC 链接相关联的数据库本地事务来支持全局事务中的非 XA 资源，因此，当某个应用程序经过一个全局事务上下文在多个 WebLogic Server 实例中访问同一 JDBC 数据源时，JTS 驱动程序会始终将 JDBC 操做路由到由该应用程序在事务中创建的第一个链接。例如，若是某个应用程序在一个服务器上启动了某个事务，访问非 XA JDBC 资源，而后对另外一个服务器进行远程方法调用（remote method invocation，简称 RMI）并访问某个使用同一底层 JDBC 驱动程序的数据源，则 JTS 驱动程序会识别出该资源具备与其余服务器上的事务相关联的链接，并会设置一个到第一个服务器上的实际链接的 RMI 重定向。对该链接的全部操做都会对创建在第一个服务器上的一个链接执行。此行为可因为与设置这些远程链接和对一个物理链接进行 RMI 调用相关联的开销而致使性能损失。

仅一个非 XA 参与者

将某个非 XA 资源（其“仿真两阶段提交”处于选中状态）注册到 WebLogic Server 事务管理器时，会使用实现 XAResource 接口的类的名称注册该资源。由于其“仿真两阶段提交”处于选中状态的全部非 XA 资源都对 XAResource 接口使用 JTS 驱动程序，因此，会使用同一名称注册全部参与某个全局事务的非 XA 资源（其“仿真两阶段提交”处于选中状态）。若是在某个全局事务中使用多个非 XA 资源，则会致使命名冲突或可能会出现试探性失败。