“记录上一个资源”事务优化
WebLogic Server 9.0 通过 JDBC 数据源支持“记录上一个资源”(Logging Last Resource,简称 LLR)事务优化。LLR 是一个性能增强选项,通过该选项,一个非 XA 资源能够与 XA 使用相同的 ACID 保证参与全局事务。LLR 是“上一个代理优化”的改进结果。它与“上一个代理优化”不同,原因在于,它对事务而言是安全的。LLR 资源使用本地事务来执行它的事务工作。WebLogic Server 事务管理器准备事务中的所有其他资源,然后根据 LLR 资源的本地事务的结果确定全局事务的提交决策。
在具有 LLR 参与者的全局两阶段提交 (2PC) 事务中,WebLogic Server 事务管理器执行下列基本步骤:
下列部分提供有关 WebLogic Server 中的 LLR 事务处理的详细信息:
有关 LLR 优点的详细信息,请参阅“配置和管理 WebLogic JDBC”中的了 解“记录上一个资源”选项 。
关于 LLR 优化事务优化
在许多情况下,全局事务会成为两阶段提交 (2PC) 事务,原因是:它涉及一个数据库操作(使用 JDBC)和一个非数据库操作(使用 JMS,如消息排队操作)。如果 2PC 事务中有一个数据库参与者,则“记录上一个资源”(LLR) 优化事务选项可消除用于数据库处理的一些 XA 开销并避免使用 JDBC XA 驱动程序(通常不如非 XA 驱动程序有效),从而大大提高事务性能。LLR 事务选项不会与仿真两阶段提交 JDBC 数据源选项和 NonXAResource 资源适配器(连接器)选项生成相同的数据风险。
“记录上一个资源”处理详细信息
在服务器引导或数据源部署时,LLR 数据源在用于缓冲数据库连接的数据库上加载或创建表。创建该表所使用的 Schema 由用于指定创建数据库连接的用户确定。如果无法创建或加载数据库表,则服务器引导将会失败。
在全局事务中,从 LLR 数据源获取的第一个连接会保留供事务专用的内部 JDBC 连接。内部 JDBC 连接保留在特定服务器(也是事务的协调器)上。对于从任何服务器上的同名数据源获取的所有连接,对它们执行的所有后续事务操作均会路由到这个相同的内部 JDBC 连接。
提交 LLR 事务时,WebLogic Server 事务管理器以透明方式应对处理。从应用程序的角度讲,事务语义保持相同,但是从内部角度讲,事务的处理方式不同于标准 XA 事务的处理方式。当应用程序提交全局事务时,WebLogic Server 事务管理器会先在 LLR 连接上提交本地事务,然后再在任何其他事务参与者上提交事务工作。对于两阶段提交事务,事务管理器还会将 2PC 记录作为同一本地事务的一部分写到数据库中。在本地事务成功完成后,事务管理器在所有其他全局事务参与者上调用提交。在所有其他事务参与者完成提交阶段 后,会释放相关的 LLR 2PC 事务记录以进行删除。在短暂的时间间隔之后或在另一本地事务中,事务管理器将从容地删除事务记录。
如果应用程序回滚全局事务或事务超时,事务管理器会在本地事务中回滚工作,并且不会在数据库中存储 2PC 记录。
要启用 LLR 事务优化,可使用“记录上一个资源”事务协议创建一个 JDBC 数据源,然后在应用程序中使用来自该数据源的数据库连接。WebLogic Server 会在数据库中自动创建所需的表。
请参阅“管理控制台联机帮助”中的创 建启用了 LLR 的 JDBC 数据源 。另请参阅“配置和管理 WebLogic JDBC”中的了 解“记录上一个资源”选项 。
LLR 数据库表详细信息
每个 WebLogic Sever 实例在 JDBC LLR 数据源将数据库连接缓冲到的数据库上维护一个数据库“LLR”表。这些表用于存储事务日志记录,并且是自动创建的。如果多个 LLR 数据源在同一 WebLogic 服务器实例上部署并且连接到相同的数据库实例和数据库 Schema,则它们也会共享相同的 LLR 表。
除非管理员选择配置 LLR 表名,否则它们会自动生成。默认的表名是 WL_LLR_
SERVERNAME
。对于一些 DBMS,表名的最大长度是 18 个字符。配置环境时,应考虑表名的最大长度。
注意: | 必须重新启动所有服务器,更改才会生效。 |
LLR 表事务日志记录
对于每个已提交的 2PC LLR 事务,事务管理器会自动在 LLR 数据库表中插入事务记录。一旦 LLR 事务完成,事务管理器便会从容地删除它们的事务记录。如果 LLR 表事务日志记录删除失败,则服务器将记录警告消息,并在以后重试删除。
如果需要移动包含 LLR 事务记录的数据库,一定要将 LLR 表内容移至新数据库中,以便事务可以正确完成。
警告: | 不要手工删除生产系统中的 LLR 事务记录或 LLR 表。如果这样做,可导致静默的试探性事务失败,这种失败不会记录下来。 |
LLR 的失败和恢复处理
一般而言,WebLogic 事务管理器以下面的方式处理事务失败:
协调服务器崩溃
如果事务的协调服务器在 LLR 资源存储其事务日志记录之前或 LLR 资源提交之前崩溃,则事务会回滚。如果服务器在提交 LLR 资源之后崩溃,事务最终会完全提交。在服务器引导期间,事务协调器将使用 LLR 资源从数据库读取事务日志记录,然后在任何参与事务的、非 LLR XA 资源上使用恢复后的信息提交所有未完成的工作。
JDBC 连接失败
如果 LLR 资源中的 JDBC 连接在 2PC 事务记录插入期间失败,则事务管理器会回滚事务。
如果 LLR 资源中的 JDBC 连接在本地事务的提交期间失败,则结果取决于事务是一阶段提交(1PC,其中 LLR 资源是唯一的参与者)还是 2PC:
服务器启动期间的 LLR 事务恢复
在服务器启动期间,每个 WebLogic 服务器的事务管理器必须恢复由服务器协调的未完成事务,包括 LLR 事务。为了这样做,每个服务器将尝试从每个 LLR 数据源的 LLR 数据库表中读取事务记录。如果服务器无法访问 LLR 数据库表,或者,如果恢复失败,则服务器将不会启动,并且事务管理器将使用错误的运行状态标记服务 器:HealthState.HEALTH_FAILED。
如果在恢复期间发生超时,可能是由于在 LLR 日志表中具有锁定行的本地事务未解决所致。必须解决这种本地事务,以便事务管理器可以确定其记录存储在锁定行中的全局事务的状态。只能使用每个数据库的特 定工具(命令因数据库而异)诊断和解决本地数据库事务。
LLR 的故障转移注意事项
使用 LLR 优化性能
优化事务协调器位置
在具有 LLR 参与者的全局事务中,WebLogic Server 自动将所有连接操作路由到事务的协调服务器。这种路由成本很高。如果将应用程序优化为在可能时直接在协调服务器上运行,并使用协调器上直接承载的连接实 例,则性能会提高。
对于开始事务的客户端应用程序,事务的协调器是客户端在事务(任何 RMI、EJB、JDBC 或 JMS 调用)下调用的第一个 WebLogic Server。在 JMS 的情况下,该服务器是承载客户端的 JMS 连接的服务器,并且不必与承载 JMS 目标的服务器相同。
对于服务器端应用程序,如果首先调用本地资源(包括 JMS 目标和 JDBC 连接),则事务的协调器是本地服务器,首先调用远程服务器(任何远程承载的 JDBC 连接、EJB、RMI 调用或 JMS 连接)时例外。这包括其他群集或域中的远程服务器。
通过 LLR 数据源执行的只读操作的各种性能
LLR 优化使插入、更新和删除操作的性能得到了显著提高。但是,对于使用 LLR 时的读操作,其性能会比使用 XA 时的读操作稍有降低。为了获得最佳性能,可能需要配置非 LLR JDBC 数据源来执行只读操作。
=========================================
本文出处: http://edocs.weblogicfans.net/wls/docs92/jta/llr.html#wp1045456