weblogic之"记录上一个资源"事务优化

sfyhip

“记录上一个资源”事务优化
WebLogic Server 9.0 通过 JDBC 数据源支持“记录上一个资源”（Logging Last Resource，简称 LLR）事务优化。LLR 是一个性能增强选项，通过该选项，一个非 XA 资源能够与 XA 使用相同的 ACID 保证参与全局事务。LLR 是“上一个代理优化”的改进结果。它与“上一个代理优化”不同，原因在于，它对事务而言是安全的。LLR 资源使用本地事务来执行它的事务工作。WebLogic Server 事务管理器准备事务中的所有其他资源，然后根据 LLR 资源的本地事务的结果确定全局事务的提交决策。
在具有 LLR 参与者的全局两阶段提交 (2PC) 事务中，WebLogic Server 事务管理器执行下列基本步骤：

• 在所有其他（符合 XA 的）事务参与者上调用准备。
  
• 将提交记录插入 LLR 参与者的表中（而不是基于文件的事务日志中）。
  
• 提交 LLR 参与者的本地事务（包括事务提交记录插入和应用程序的SQL 工作）。
  
• 在所有其他事务参与者上调用提交。
  
• 在事务成功完成后，从容地将数据库事务日志条目删除（作为未来事务的一部分）。
  

下列部分提供有关 WebLogic Server 中的 LLR 事务处理的详细信息：

• 关于 LLR 优化事务优化
  
• “记录上一个资源”处理详细信息
  
• LLR数据库表详细信息
  
• LLR的失败和恢复处理
  
• 使用 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”中的了解“记录上一个资源”选项。
有关数据源配置以及使用要求和限制的列表，请参阅：

• "“配置和管理 WebLogic JDBC”中的 LLR数据源的编程注意事项和限制
  
• "“配置和管理 WebLogic JDBC”中的 LLR数据源的管理注意事项和限制
  

LLR 数据库表详细信息
每个 WebLogic Sever 实例在 JDBC LLR 数据源将数据库连接缓冲到的数据库上维护一个数据库“LLR”表。这些表用于存储事务日志记录，并且是自动创建的。如果多个 LLR 数据源在同一 WebLogic 服务器实例上部署并且连接到相同的数据库实例和数据库 Schema，则它们也会共享相同的 LLR 表。
除非管理员选择配置 LLR 表名，否则它们会自动生成。默认的表名是 WL_LLR_SERVERNAME。对于一些 DBMS，表名的最大长度是 18 个字符。配置环境时，应考虑表名的最大长度。
请注意下面有关 LLR 数据库表的限制：

• 如果在引导期间无法访问 LLR 表，则服务器不会引导。LLR 事务记录必须可在恢复期间用于正确解决不确定的事务，恢复在服务器启动时自动运行。
  
• 多个服务器不得共享同一个 LLR 表。在服务器启动时，WebLogic Server 会进行检查以确保在创建表时 JDBC 数据源的域和服务器名称与存储在表中的域和服务器名称相同。如果 WebLogic Server 检测到多个服务器正在共享同一个 LLR 表，则 WebLogic Server 将关闭一个或多个服务器。
  

要更改用于存储资源的事务日志记录的表名，请执行下列步骤：

• 在管理控制台窗口左上角的“更改中心”中，单击“锁定并编辑”以启动配置编辑会话。
  
• 在“服务器: 配置: 常规”页上，单击“高级”以显示高级配置选项。请参阅
  
• 在“JDBC LLR 表名”中，输入用于存储资源的事务记录的表的名称，然后单击“保存”。请参阅服务器：配置：常规。
  
• 在用于部署启用 LLR 的数据源的每台服务器上，重复步骤 2 和3。
  
• 在“更改中心”中单击“激活更改”。
  

　　

注意：	必须重新启动所有服务器，更改才会生效。

LLR 表事务日志记录
对于每个已提交的 2PC LLR 事务，事务管理器会自动在 LLR 数据库表中插入事务记录。一旦 LLR 事务完成，事务管理器便会从容地删除它们的事务记录。如果 LLR 表事务日志记录删除失败，则服务器将记录警告消息，并在以后重试删除。
如果需要移动包含 LLR 事务记录的数据库，一定要将 LLR 表内容移至新数据库中，以便事务可以正确完成。
　　

警告：	不要手工删除生产系统中的 LLR 事务记录或 LLR 表。如果这样做，可导致静默的试探性事务失败，这种失败不会记录下来。

LLR 的失败和恢复处理
一般而言，WebLogic 事务管理器以下面的方式处理事务失败：

• 对于在尝试本地事务提交前发生的两阶段提交错误，事务管理器会立即引发事务回滚异常。
  
• 对于在本地事务提交过程中发生的两阶段提交错误，具体行为取决于是否将事务记录写至数据库中：
  
  
  
  • 如果写入记录，则事务管理器提交事务。
    
  • 如果不写入记录，则事务管理器回滚事务。
    
  • 如果不知道是否写入记录，则事务管理器会引发不明确的提交失败异常，并每 5 秒钟进行一次完成事务的尝试，直到事务放弃超时。如果事务仍旧未完成，则事务管理器会记录一条放弃事务消息。
    
  
  

协调服务器崩溃
如果事务的协调服务器在 LLR 资源存储其事务日志记录之前或 LLR 资源提交之前崩溃，则事务会回滚。如果服务器在提交 LLR 资源之后崩溃，事务最终会完全提交。在服务器引导期间，事务协调器将使用 LLR 资源从数据库读取事务日志记录，然后在任何参与事务的、非 LLR XA 资源上使用恢复后的信息提交所有未完成的工作。
JDBC 连接失败
如果 LLR 资源中的 JDBC 连接在 2PC 事务记录插入期间失败，则事务管理器会回滚事务。
如果 LLR 资源中的 JDBC 连接在本地事务的提交期间失败，则结果取决于事务是一阶段提交（1PC，其中 LLR 资源是唯一的参与者）还是 2PC：

• 对于 1PC 事务，事务将完全提交、完全回滚或阻塞（等待本地事务的解决）。因为事务最终完全提交或完全回滚，所以事务的结果是完全 ACID。
  
• 对于 2PC 事务，结果如 LLR的失败和恢复处理中所述。
  

服务器启动期间的 LLR 事务恢复
在服务器启动期间，每个 WebLogic 服务器的事务管理器必须恢复由服务器协调的未完成事务，包括 LLR 事务。为了这样做，每个服务器将尝试从每个 LLR 数据源的 LLR 数据库表中读取事务记录。如果服务器无法访问 LLR 数据库表，或者，如果恢复失败，则服务器将不会启动，并且事务管理器将使用错误的运行状态标记服务器：HealthState.HEALTH_FAILED。
如果在恢复期间发生超时，可能是由于在 LLR 日志表中具有锁定行的本地事务未解决所致。必须解决这种本地事务，以便事务管理器可以确定其记录存储在锁定行中的全局事务的状态。只能使用每个数据库的特定工具（命令因数据库而异）诊断和解决本地数据库事务。
LLR 的故障转移注意事项
请考虑以下与 LLR 的故障转移相关的注意事项和限制：

• LLR 事务仍旧需要基于文件的事务日志 (TLog)：
  
  
  
  • TLog 仍旧存储事务管理器“检查点”记录
    
  • 在故障转移时必须仍旧可以访问或复制 TLog
    
  
  
• LLR 支持服务器迁移和事务恢复服务迁移。要使用事务恢复服务迁移，请确保每个 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