260 likes | 437 Views
Ed Felt & Sriram Srinivasan ed.felt@bea.com, srirams@bea.com BEA Systems, Inc. Advanced Distributed Transaction Processing with BEA WebLogic Server ™ 6.0. Agenda. Why use transactions? What capabilities does BEA WebLogic Server 6.0 provide? How to program? How to configure and monitor?
E N D
Ed Felt & Sriram Srinivasan ed.felt@bea.com, srirams@bea.com BEA Systems, Inc. Advanced Distributed Transaction Processing with BEA WebLogic Server™ 6.0
Agenda • Why use transactions? • What capabilities does BEA WebLogic Server 6.0 provide? • How to program? • How to configure and monitor? • References • Questions & Answers
Benefit #1: Data Consistency • Ensure data integrity when accessing more than one data store, especially in distributed environment • Simple model for application programmer: A- atomic C- consistent I- isolated D- durable
Benefit #2: Monitoring & Management • A transaction is a higher-level unit of work than a database query or an object invocation • BEA WebLogic Server allows transactions to be given a semantic name (“TransferFunds” or “ReserveSeat” or “CheckOut”) • Transaction Name is reported in error messages • Statistics subtotals categorized by Transaction Name
Benefit #3: Timeouts & Overload Protection • Transactions are subject to timeout • 30 second default • Application code (or the EJB container) can mark a transaction “rollback only” • In an overloaded system, BEA WebLogic Server: • Times out requests (who waits 30+ seconds for a Web page to return?) • Avoids wasted work on “doomed” transactions • Eventually refuses to begin new transactions when there are too many already running (configurable parameter)
Supported Configurations • Multiple servers may participate in a distributed transaction • Clustered or non-clustered • Need not be in same administrative domain • Requires connectivity and permissions • Clients may initiate transactions and infect multiple servers • Commit responsibility is handed off to a server • Clients may not enlist resources or register synchronization callbacks • Multiple XA resources may participate in same transaction • More than one coordinated by “two-phase commit” algorithm
Relationship with Other Subsystems • JDBC • Recognized any JDBC driver that implements JDBC 2.0 XA extensions • BEA provides Type 2 XA driver for Oracle 8.1.6 client • JDBC wrapper enhances performance • JMS • Supports XA, can participate in JTA transactions • All storage types: database, file, non-persistent • EJB • Automatically manages transactions based on EJB’s deployment descriptor
High-Level Architecture EJB Container Application JTA JDBC JMS JTA JDBC Wrapper JDBC Transaction Manager XA-Capable Resource XA
Performance Optimizations • Boxcar algorithm for multiple commit records per I/O • One-phase commit optimization • Read-only branch optimization • Dynamic resource enlistment optimization • Piggy-back transaction propagation • Multiple operations per coordination message • Asynchronous, parallel coordination architecture with retry
Programming APIs • Good news! In many cases, transactions are controlled by the EJB Container, and an application programmer writes no code for transactions • The UserTransaction object provides simple begin/commit/rollback functionality for applications that need to explicitly demarcate transaction boundaries • More powerful transaction objects normally used by the Application Server and EJB Container are available to applications with complex transactional requirements • BEA WebLogic Server extensions for convenience and added value
JTA Interfaces • UserTransaction • Basic methods to begin, commit, rollback transactions and get/set status • TransactionManager • Adds suspend, resume, get thread’s current Transaction object • Transaction • Represents on transaction, controls enlistment and synchronization • Synchronization • Callback interface for before/after completion notification • XAResource • Xid • Various exceptions and status codes
BEA WebLogic Server Extensions • weblogic.transaction.TxHelper • Static methods to get Transaction, UserTransaction, and TransactionManager objects • weblogic.transaction.Transaction • Get/set transaction name, transaction properties • Get/set rollback reason • Get timeout information • Get Xid • weblogic.transaction.TransactionManager • XA resource registration • Get transaction object by Xid • Force suspend/resume (without XA calls)
Configuration Parameters (Per Domain) • Transaction Timeout Seconds • Default number of seconds for transaction timeout, unless overridden by API call or EJB container • Abandon Timeout Seconds • After X number of seconds, stop trying to resolve branch(es) of a committed transaction and log an error • Should never happen unless resource dies during commit processing and does not come back • Forget Heuristics • When resource reports a heuristic completion, log an error message and then tell resource to “forget”about that transaction
Configuration Parameters (Per Domain) • Before Completion Iteration Limit • Maximum number of times a server will iterate through registered Synchronization objects for the same transaction • Prevents infinite loops when one Synchronization callback causes another Synchronization object registration • Max Transactions • Maximum number of transactions that can be simultaneously active on a server • Max Unique Name Statistics • Maximum number of transaction names remembered for categorizing statistic subtotals
Configuration Parameters (Per Server) • Transaction Log File Prefix • Each server that coordinates a two-phase commit transaction writes to the transaction log at commit time and reads the transaction log during crash recovery • A transaction log is stored in multiple files • Space is reclaimed automatically • Never delete these files • Default location is server’s current directory • Highly reliable file system is recommended (RAID, etc.) • File naming convention: Prefix + ServerName + 9999 + “.tlog” (9999 = unique number)
Configuration Parameters (JDBC) • Transaction branches • Connection pool name determines transaction branch qualifier • Different pool names cause separate branches, even if connected to same database • Databases typically provide lock isolation between branches, shared locks within a branch • Benefits of multiple branches: • Lock isolation protects independently developed components from unexpected cross-interference • Drawbacks of multiple branches: • Lock conflicts can cause deadlock/timeout • More overhead in transaction coordination, more XA calls
Configuration Parameters (JDBC) • JDBCTxDataSource wrapper for non-XA database drivers • If EnableTwoPhaseCommit=“false” (the default) and a non-XA JDBC driver is supplied, commit() will fail unless this is the only transaction participant • If EnableTwoPhaseCommit=“true” a non-XA JDBC driver may participate in a transaction with multiple participants, however there is a risk that the non-XA driver might fail at commit time • This is reported as a heuristic rollback exception
Monitoring • Counters • Overall • Subtotal by XAResource • Subtotal by Transaction name • Specific transactions • List transactions more than XX seconds old • “Old” transactions are the most interesting ones
Coming Attractions • Ongoing integration testing and cooperation with XA resource providers • Support for transaction export/import to/from external systems via interposed gateway architecture • Additional internal enhancements for reliability, overload tolerance, and performance • Additional management, monitoring, statistics
References • Specifications • http://www.java.sun.com/products/jta • http://www.java.sun.com/j2ee • BEA WebLogic Server 6.0 Documentation • http://e-docs.bea.com • News Group • news://newsgroups.bea.com/weblogic.developer.interest.transaction