Ed Felt & Sriram Srinivasan ed.felt@bea, srirams@bea BEA Systems, Inc

  • View

  • Download

Embed Size (px)


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? - PowerPoint PPT Presentation

Text of Ed Felt & Sriram Srinivasan ed.felt@bea, srirams@bea BEA Systems, Inc

  • Ed Felt & Sriram Srinivasan ed.felt@bea.com, srirams@bea.comBEA Systems, Inc.Advanced Distributed Transaction Processing with BEA WebLogic Server 6.0

  • AgendaWhy use transactions?What capabilities does BEA WebLogic Server 6.0 provide?How to program?How to configure and monitor?ReferencesQuestions & Answers

  • Benefit #1: Data ConsistencyEnsure data integrity when accessing more than one data store, especially in distributed environmentSimple model for application programmer:A - atomicC - consistentI - isolatedD - durable

  • Benefit #2: Monitoring & ManagementA transaction is a higher-level unit of work than a database query or an object invocationBEA WebLogic Server allows transactions to be given a semantic name (TransferFunds or ReserveSeat or CheckOut)Transaction Name is reported in error messagesStatistics subtotals categorized by Transaction Name

  • Benefit #3: Timeouts & Overload ProtectionTransactions are subject to timeout30 second defaultApplication code (or the EJB container) can mark a transaction rollback onlyIn an overloaded system, BEA WebLogic Server:Times out requests (who waits 30+ seconds for a Web page to return?)Avoids wasted work on doomed transactionsEventually refuses to begin new transactions when there are too many already running (configurable parameter)

  • Supported ConfigurationsMultiple servers may participate in a distributed transactionClustered or non-clusteredNeed not be in same administrative domainRequires connectivity and permissionsClients may initiate transactions and infect multiple serversCommit responsibility is handed off to a serverClients may not enlist resources or register synchronization callbacksMultiple XA resources may participate in same transactionMore than one coordinated by two-phase commit algorithm

  • Relationship with Other SubsystemsJDBCRecognized any JDBC driver that implements JDBC 2.0 XA extensionsBEA provides Type 2 XA driver for Oracle 8.1.6 clientJDBC wrapper enhances performanceJMSSupports XA, can participate in JTA transactionsAll storage types: database, file, non-persistentEJBAutomatically manages transactions based on EJBs deployment descriptor

  • High-Level ArchitectureTransactionManagerXA-CapableResource

    EJB ContainerApplicationJDBC WrapperJTAJDBCJMSXAJDBCJTA

  • Performance OptimizationsBoxcar algorithm for multiple commit records per I/OOne-phase commit optimizationRead-only branch optimizationDynamic resource enlistment optimizationPiggy-back transaction propagationMultiple operations per coordination messageAsynchronous, parallel coordination architecture with retry

  • Programming APIsGood news! In many cases, transactions are controlled by the EJB Container, and an application programmer writes no code for transactionsThe UserTransaction object provides simple begin/commit/rollback functionality for applications that need to explicitly demarcate transaction boundariesMore powerful transaction objects normally used by the Application Server and EJB Container are available to applications with complex transactional requirementsBEA WebLogic Server extensions for convenience and added value

  • JTA InterfacesUserTransactionBasic methods to begin, commit, rollback transactions and get/set statusTransactionManagerAdds suspend, resume, get threads current Transaction objectTransactionRepresents on transaction, controls enlistment and synchronizationSynchronizationCallback interface for before/after completion notificationXAResourceXidVarious exceptions and status codes

  • BEA WebLogic Server Extensionsweblogic.transaction.TxHelperStatic methods to get Transaction, UserTransaction, and TransactionManager objectsweblogic.transaction.TransactionGet/set transaction name, transaction propertiesGet/set rollback reasonGet timeout informationGet Xidweblogic.transaction.TransactionManagerXA resource registrationGet transaction object by XidForce suspend/resume (without XA calls)

  • Configuration Parameters (Per Domain)Transaction Timeout SecondsDefault number of seconds for transaction timeout, unless overridden by API call or EJB containerAbandon Timeout SecondsAfter X number of seconds, stop trying to resolve branch(es) of a committed transaction and log an errorShould never happen unless resource dies during commit processing and does not come backForget HeuristicsWhen resource reports a heuristic completion, log an error message and then tell resource to forgetabout that transaction

  • Configuration Parameters (Per Domain)Before Completion Iteration LimitMaximum number of times a server will iterate through registered Synchronization objects for the same transactionPrevents infinite loops when one Synchronization callback causes another Synchronization object registrationMax TransactionsMaximum number of transactions that can be simultaneously active on a serverMax Unique Name StatisticsMaximum number of transaction names remembered for categorizing statistic subtotals

  • Configuration Options

  • Configuration Parameters (Per Server)Transaction Log File PrefixEach server that coordinates a two-phase commit transaction writes to the transaction log at commit time and reads the transaction log during crash recoveryA transaction log is stored in multiple filesSpace is reclaimed automaticallyNever delete these filesDefault location is servers current directoryHighly reliable file system is recommended (RAID, etc.)File naming convention:Prefix + ServerName + 9999 + .tlog (9999 = unique number)

  • Configuration Parameters (JDBC)Transaction branchesConnection pool name determines transaction branch qualifierDifferent pool names cause separate branches, even if connected to same databaseDatabases typically provide lock isolation between branches, shared locks within a branchBenefits of multiple branches:Lock isolation protects independently developed components from unexpected cross-interferenceDrawbacks of multiple branches:Lock conflicts can cause deadlock/timeoutMore overhead in transaction coordination, more XA calls

  • Configuration Parameters (JDBC)JDBCTxDataSource wrapper for non-XA database driversIf EnableTwoPhaseCommit=false (the default) and a non-XA JDBC driver is supplied, commit() will fail unless this is the only transaction participantIf 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 timeThis is reported as a heuristic rollback exception

  • MonitoringCountersOverallSubtotal by XAResourceSubtotal by Transaction nameSpecific transactionsList transactions more than XX seconds oldOld transactions are the most interesting ones

  • Monitoring Summary

  • Monitoring Stats by Name

  • Monitoring Stats by Resource

  • Monitoring Individual Transactions

  • Coming AttractionsOngoing integration testing and cooperation with XA resource providersSupport for transaction export/import to/from external systems via interposed gateway architectureAdditional internal enhancements for reliability, overload tolerance, and performanceAdditional management, monitoring, statistics

  • ReferencesSpecificationshttp://www.java.sun.com/products/jtahttp://www.java.sun.com/j2eeBEA WebLogic Server 6.0 Documentationhttp://e-docs.bea.comNews Groupnews://newsgroups.bea.com/weblogic.developer.interest.transaction

  • Questions & Answers