You are on page 1of 26

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

Application

EJB Container JDBC


JDBC
JTA JMS
JTA Wrapper
JDBC

Transaction XA-Capable
Manager XA Resource
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 Options
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
Monitoring Summary
Monitoring Stats by Name
Monitoring Stats by Resource
Monitoring Individual Transactions
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
Questions & Answers

You might also like