1. COM+ Transactions Writing Components In Visual Basic ® Brian A. Randell DevelopMentor 1-304

3. mentor developmentor Hands-on training for hardcore developers Hands-on training for hardcore developers  Guerrilla training courses:  Guerrilla VB & Guerrilla COM (C++)  COM courses with banker’s hours:  Essential COM+ for VB programmers  Essential COM+ for C++ programmers Lots of other courses too! Lots of other courses too!

4. Agenda OLTP Concepts OLTP Concepts  The ACID rules, isolation & locking  Writing transactions Distributed Transactions Distributed Transactions  Transaction managers & the 2-phase commit protocol COM+ Transactions COM+ Transactions  Creating objects inside a transaction  Controlling a distributed transaction’s outcome

5. Transaction Fundamentals Most business applications use data in some way Most business applications use data in some way  Some apps are concerned with querying & analyzing data  Other apps are primarily concerned with modifying data  Apps that modify data and have many users are commonly referred to as on-line transaction processing (OLTP) systems

6. What Is A Transaction? Imagine an application that processes purchase orders Imagine an application that processes purchase orders  Each order requires 3 database modifications 1) Order quantity must be deducted from inventory 2) Purchase price must be charged to customer 3) Order record must be inserted in Orders table These three modifications make up one transaction (TX) These three modifications make up one transaction (TX)  These modifications represent a single unit of work

7. The ACID Rules A transaction must meet 4 basic requirements A transaction must meet 4 basic requirements It must be atomic It must be atomic  A transaction must be an all-or-nothing proposition everything must be successfully written or nothing should be written It must be consistent It must be consistent  The data used by an application is never left in an invalid state after a transaction has completed

8. The ACID Rules It must be isolated It must be isolated  The uncommitted changes of one user are never seen by another user. Systems that run concurrent transactions require blocking It must be durable It must be durable  Once a transaction has committed, the data source has stored all changes in persistent storage and these changes can be recovered in the event of a system failure

9. Isolation & Locking A transaction has one of two outcomes A transaction has one of two outcomes  Successful transactions are committed  Unsuccessful transactions are aborted Isolation is required during a transactions Isolation is required during a transactions  Uncommitted changes might be rolled back  Reading uncommitted changes can lead to inconsistent data  TX2 cannot see the uncommitted changes of other TX1

10. Potential Concurrency Problems Naïve concurrent execution of transactions would yield the following problems: Naïve concurrent execution of transactions would yield the following problems:  Lost Updates  Dirty Reads  Unrepeatable Reads  Phantoms Properly isolated transactions do not exhibit any of these problems Properly isolated transactions do not exhibit any of these problems

11. Degrees Of Isolation Whether or not these problems occur depends on a transaction’s degree of isolation Whether or not these problems occur depends on a transaction’s degree of isolation Common Name 1203Degree ReadUncommittedReadCommittedChaosSerializable AKABrowseCursorStabilityIsolated NoYesNo YesYesNo Lost Updates? No Dirty Reads? No Unrepeatable Reads? YesYesYesNo Phantoms?YesYesYesNo 2.999 RepeatableRead No No No Yes

12. Isolation & Locking Isolation is provided by a lock manager Isolation is provided by a lock manager  A data source such as DBMS provides a lock manager  Uncommitted changes are isolated with write locks  write locks are also known as exclusive locks  Additional consistency is provided through read locks  read locks are also known as shared locks Locks are placed on data items Locks are placed on data items  Could be a file, a table, a page or a record

13. Locking Basics Many concurrent systems use locks to implement isolation levels Many concurrent systems use locks to implement isolation levels Model relies on two types of locks to avoid “problems” but allow maximum concurrency Model relies on two types of locks to avoid “problems” but allow maximum concurrency Read (shared) locks allow multiple transactions to read a piece of state concurrently Read (shared) locks allow multiple transactions to read a piece of state concurrently Write (exclusive) locks allow exactly one transaction to write to a piece of state Write (exclusive) locks allow exactly one transaction to write to a piece of state  Requires that no read locks are outstanding  Classic Win32 synchronization primitives (e.g., Mutex, Critical Section) are write locks

14. Lock Managers & Blocking Write locks block all other locks Write locks block all other locks  One transaction blocks all other transactions Read locks only block write locks Read locks only block write locks  Many transactions can read the same data item at the same time Here’s how it works Here’s how it works Attempt Read Lock Attempt Write Lock Read Lock Held Write Lock Held No Lock Held Lock Granted Request Blocked Lock Granted Request Blocked

15. Isolation Levels How long are locks held? How long are locks held?  Write locks are always held until the end of the transaction  Read locks might or might not be held until the end of the transaction The isolation level adjusts the duration and behavior of read locks The isolation level adjusts the duration and behavior of read locks  Higher isolation provides better consistency  Lower isolation provides better concurrency

16. Adjusting Isolation Levels Occasionally useful to loosen isolation requirements to increase overall system throughput Occasionally useful to loosen isolation requirements to increase overall system throughput  Must tolerate one or more problems!! Adjustment of isolation levels is not always possible Adjustment of isolation levels is not always possible  Some data managers don’t allow it As we’ll see, COM+ has a specific setting in mind! As we’ll see, COM+ has a specific setting in mind!

17. Running Local Transactions Local transactions are managed by a DBMS’s transaction manager Local transactions are managed by a DBMS’s transaction manager  The transaction manager works together with the lock manager How do you run a local transaction? How do you run a local transaction?  You write explicit commands to start, commit and rollback the transaction  Transaction logic is usually embedded in a SQL batch or a stored procedure

18. Running Local Transactions DBMSSQLSERVR.EXE COM+ Application Activity ADOConn VB Object Activity ADOConn Activity ADOConn Client 1 Client 2 Client N Transaction Manager LockManager Data

19. Programming Local Tx’s #1 This examples uses an ADO connection This examples uses an ADO connection  ADO connection object provides transaction control  This technique can be used with any ODBC or OLE-DB data source that supports transactions  Controlling transactions from an ADO connection can be expensive due to the need to use use extra round trips to DBMS to start/commit/abort

20. ADO Example Dim conn As Connection Set conn = New Connection conn.Open "DSN=Market;UID=sa;PWD=" conn.IsolationLevel = adXactSerializable conn.BeginTrans ' SQL statements omitted for clarity ' SQL statements omitted for clarity conn.Execute SQL_DecrementInventory conn.Execute SQL_DecrementInventory conn.Execute SQL_ChargeCustomer conn.Execute SQL_ChargeCustomer conn.Execute SQL_AddOrder conn.Execute SQL_AddOrderconn.CommitTrans

21. Programming Local Tx’s #2 Control the transaction using SQL Control the transaction using SQL  SQL logic is embedded into a SQL batch or stored procedure  Isolation level can be adjusted on a statement-by-statement basis using hints  This approach usually requires SQL that is specific to a particular DBMS  Writing fast OLTP code works across DBMS’s is usually impossible

22. T-SQL Example -- set isolation level to serializable SET TRANSACTION ISOLATION LEVEL SERIALIZABLE -- run transaction to purchase a product BEGIN TRANSACTION -- decrement product quantity from inventory -- decrement product quantity from inventory UPDATE Products UPDATE Products SET Quantity = Quantity - 1 SET Quantity = Quantity - 1 WHERE Product = 'Dog' WHERE Product = 'Dog' -- charge price to customer account -- charge price to customer account UPDATE Customers UPDATE Customers SET AccountBalance = AccountBalance + 20 SET AccountBalance = AccountBalance + 20 WHERE Customer = 'Bob' WHERE Customer = 'Bob' -- add order record -- add order record INSERT Orders(Customer, Product, Quantity, Price) INSERT Orders(Customer, Product, Quantity, Price) VALUES('Bob', 'Dog', 1, 20) VALUES('Bob', 'Dog', 1, 20) COMMIT TRANSACTION

23. Distributed Transactions Local transactions only work when all the data lives in one place Local transactions only work when all the data lives in one place  For example, all the data lives in a single DBMS  The transaction manager inside the DBMS enforces ACID rules What if the data lives in multiple data sources? What if the data lives in multiple data sources?  The problem is much more difficult  Commit/Abort logic must be coordinated across multiple data sources

24. 2-Phase Commit Protocol Many vendors offer products that solve the problems of distributed transactions in the same way Many vendors offer products that solve the problems of distributed transactions in the same way CICS from IBM, TUXEDO from BEA System and COM+ from Microsoft all use similar high-level architectures CICS from IBM, TUXEDO from BEA System and COM+ from Microsoft all use similar high-level architectures Architecture uses an abstraction called the transaction manager and a protocol called 2-phase commit Architecture uses an abstraction called the transaction manager and a protocol called 2-phase commit

25. The Microsoft DTC The DTC is the Distributed Transaction Coordinator The DTC is the Distributed Transaction Coordinator  It is Microsoft's transaction manager It coordinates distributed transactions and enforces the ACID rules It coordinates distributed transactions and enforces the ACID rules It executes the 2-phase commit protocol It executes the 2-phase commit protocol Originally released as a part of SQL Server Originally released as a part of SQL Server  Now an integrated part of MTS & COM+

26. Computer 3 RM3 - ORACLE Participating DTC Computer 2 RM2 -SQL Server Participating DTC Computer 1 The Coordinating DTC RM1 - MSMQ A Distributed Transaction Data Data Your Tx COM+ Application Queue RM Proxy

27. COM+ Transactions COM+ transactions make your life much easier COM+ transactions make your life much easier  COM+ provides a programming model with declarative transactions  COM+ transaction represents a set of COM objects  You create your objects inside an COM+ transaction  Your objects establish and enlist connections to resource managers  Your objects read and write data inside the scope of a DTC transaction

28. COM+ Transactions What’s different about this model? What’s different about this model?  You never explicitly start a transaction  You never explicitly commit a transaction  You never explicitly abort a transaction So how does it work? So how does it work?  A COM+ transaction is a friendly wrapper around a DTC transaction

29. A Tale Of Two Transactions There are really two transactions There are really two transactions  MTS/COM+ creates a logical transaction when an object is created from a component marked Requires or Requires New  MTS/COM+ creates a physical transaction by calling to DTC transaction dispenser and invoking BeginTransaction  MTS delays start of DTC transaction until object activation time  COM+ further delays start of DTC transaction until first "interesting" call  DTC transaction is created with isolation level of serializable  DTC transaction has a default time out interval of 60 seconds The MTS/COM+ runtime controls the physical DTC transaction The MTS/COM+ runtime controls the physical DTC transaction  MTS/COM+ calls Commit or Abort when the root object is deactivated  You can change things in the logical transaction to affect what goes on with the physical transaction

30. Creating Objects In A Transaction A transaction must exist within the scope of an activity A transaction must exist within the scope of an activity  This eliminates problems with concurrency and reentrancy  Secondary objects should be created with CreateInstance in MTS  Secondary objects should be created with CreateObject in COM+  Every configured component has a Transaction Support property Configured components can be marked as... Configured components can be marked as...  Requires a transaction: inherits transaction of creator, COM+ creates one if necessary  Requires a new transaction: never inherits transaction of creator, COM+ always creates one  Supports transactions: inherits transaction of creator if present, otherwise runs without  Does not support transactions: never inherits transaction of creator, always runs without

31. ' root object is set to: Requires Transaction ' this code assumes COM+ as opposed to MTS Public Sub CreateOtherObjects() Dim Joe As CJoe, Brian As CBrian Dim Joe As CJoe, Brian As CBrian Dim Jason As CJason, Ted As CTed Dim Jason As CJason, Ted As CTed Set Joe = CreateObject("MyDll.CJoe") Set Joe = CreateObject("MyDll.CJoe") Set Brian = CreateObject("MyDll.CBrian") Set Brian = CreateObject("MyDll.CBrian") Set Jason = CreateObject("MyDll.CJason") Set Jason = CreateObject("MyDll.CJason") Set Ted = CreateObject("MyDll.CTed") Set Ted = CreateObject("MyDll.CTed") End Sub CJoe: Requires CBrian: Requires new CJason: supports CTed: does not support Creating Secondary Objects

32. COM+ Runtime Transaction 1 Ted Client Transaction 2 Root Jason Joe Brian Activity boundary

33. COM+ Transaction DoomedFALSE Commit/Abort Behavior When the root object is deactivated… When the root object is deactivated…  The MTS/COM+ runtime calls either Commit or Abort  There are 3 flags you need to know about Context A HappyTRUE Done FALSE Root Object COM+Proxy Client

34. Controlling A Declarative Transaction The ObjectContext interface allows objects to vote The ObjectContext interface allows objects to vote  Any object that dies unhappy will doom transaction to failure  An secondary object which doesn't vote gives passive consent to commit changes  Root object MUST call SetComplete to commit changes Important methods in the ObjectContext interface Important methods in the ObjectContext interface  DisableCommit: object is saying "I'm unhappy but I’m not done - someone could still make me happy."  EnableCommit: object is saying "I'm happy but I’m not done. Someone could still change my mind."  SetComplete: object is saying "I'm happy and I’m done. I am now ready to be deactivated."  SetAbort: object is saying "I'm unhappy and I’m done. I will now deactivate and doom transaction"

35. The IContextState Interface ObjectContext methods set both DONE bit and HAPPY bit ObjectContext methods set both DONE bit and HAPPY bit  SetComplete, SetAbort, DisableCommit, EnableCommit COM+ introduces the IConstextState interface COM+ introduces the IConstextState interface  SetMyTransactionVote  GetMyTransactionVote  SetDeactivateOnReturn  GetDeactivateOnReturn How does IContextState differ from ObjectContext How does IContextState differ from ObjectContext  You can read the value of the done bit and the happy bit  The methods raise errors if the object isn't in a transaction Should you use IContextState instead of ObjectContext Should you use IContextState instead of ObjectContext  No real need – unless you want to read the happy or done bit

36. Multi-Object Transaction Issues Creating secondary objects in a transaction Creating secondary objects in a transaction  Each transaction has a root object the root is created by a base client in the simplest scenario  All objects in a transaction must share the same activity This eliminates issues with concurrency and synchronization  Transaction Support property must be set properly  In COM+, the root should create secondary objects by calling CreateObject  In MTS, the root should create secondary objects by calling CreateInstance  Remember the New operator can get you into trouble on either platform Secondary objects usually connect to RM to access data Secondary objects usually connect to RM to access data  MTS/COM+ automatically enlists connections in current transaction when made to a valid resource manager (RM) through a RM proxy  Each secondary object gets to vote on the transaction's outcome

37. How Does Voting Work? Any object can prevent the transaction from committing Any object can prevent the transaction from committing  If a secondary object is deactivated in an unhappy state Then MTS/COM+ sets the transaction's doomed flag to true  Setting the doomed flag to true is irreversible COM+ Transaction Doomed True/False Client Secondary Object 1 Secondary Object 2 Secondary Object 3 RootObject proxy HappyDone proxy HappyDone proxy HappyDone proxy HappyDone

38. Writing Commit/Abort Logic Each transaction must have a root object Each transaction must have a root object  This usually defines the client's entry point into the package  Root should always call SetComplete or SetAbort to release tx Secondary objects can also vote in transaction outcome Secondary objects can also vote in transaction outcome  If any secondary object can vote to rollback the transaction  MTS/COM+ sets doomed flag to true when deactivating an unhappy object Root must somehow discover transaction is doomed Root must somehow discover transaction is doomed  No way for root to discover this through ObjectContext interface  Calling SetComplete in root after a secondary object has set the doomed flag will result in a runtime error  An attempt to activate an object in a doomed transaction results in an error  Secondary objects should raise errors when voting to rollback

39. Watch Out When Calling SetAbort In COM+ There's an ugly bug in COM+ that isn’t in MTS There's an ugly bug in COM+ that isn’t in MTS  Secondary objects should not raise an error after setting the done bit  The bug steps on the error message and the root gets the infamous error message "method '~' of object '~' failed"  This bug breaks MTS code when you move your application to Win2K  The bug will be fixed in Win2K service pack1 Here's a workaround until the bug is fixed Here's a workaround until the bug is fixed  Secondary objects should avoid calling SetAbort before raising an error  Secondary objects should call SetMyTransactionVote or DisableCommit instead – just don’t set the done bit to true What are the worst things about is this bug a problem What are the worst things about is this bug a problem  MTS code will break when run under COM+  You can’t really create a component that can act as either the root or as a secondary object

40. Remote Computer 2 Remote Computer 2 ORACLE (RM2) Participating DTC Remote Computer 1 SQL Server (RM1) Participating DTC COM+ Computer Coordinating DTC COM+ Application COM+ Runtime User’s Computer Base Client COM+ Transaction Data Data DTC Proxy Layer Root Secondary Secondary Enlisting Resource Managers

41. Going Stateless Transactional objects typically die after each method call Transactional objects typically die after each method call  Calling SetComplete or SetAbort on ObjectContext tells MTS/COM+ that the object's work is done and it can be deactivated (i.e. destroyed)  Object destruction occurs in interception layer in method post- processing MTS/COM+ hides object destruction from clients MTS/COM+ hides object destruction from clients  The client holds a persistent connection to system-supplied proxy  MTS/COM+ uses just-in-time activation to create a new object for each method called from the client How does this affect the way you program? How does this affect the way you program?  It helps you to release your transactions ASAP  It discards state acquired from RMs before locks are released this is required to enforce the ACID rules  This can make design more difficult because objects cannot hold state

42. Stateless Versus Stateful Components Statelessness is a strange side-effect of declarative transactions Statelessness is a strange side-effect of declarative transactions  You must design around the assumption that state is lost on every method call to a transactional object  Many misinformed authorities have suggested that the point of calling SetComplete is aggressive memory reclamation (this is totally untrue)  Deactivation and JIT reactivation is only for transactional objects and poolable objects (there is no reason to set the done bit in any other case) Objects that need transactions can hold state Objects that need transactions can hold state  Many designs require that state is held across method calls losing state implies that object must be recreated & reinitialized on a per call basis  Many advantages of MTS/COM+ apply to non-transactional objects as well stateful objects benefit from thread pooling, COM+ security, configuration mgmt, etc.

43. Consider Using The Lower Design Approach It’s often advantageous to place a a non-transactional object between a transactional object and the client It’s often advantageous to place a a non-transactional object between a transactional object and the client  Client can hold server-side state and still run declarative transactions  Non-transaction object can shield client from errors thrown by the DTC

44. Consider Using The Lower Design Approach Client Application 1 COM+ Application RootObject Happy Bit TRUE Context A Stub Done Bit TRUE Proxy Client Client Application 2 Context B Stub Proxy Client RootObject Happy Bit TRUE Context C Done Bit TRUE Non-TXObject Proxy

45. When Should You Use Transactions? You should use transactions only when you need to enforce the ACID rules You should use transactions only when you need to enforce the ACID rules  They're expensive and reduce scalability when used unnecessarily  Only run transactions when you need acquire locks across a set of operations  You don’t need an explicit transaction for an individual SQL statement the DBMS runs each SQL statement as an individual transaction automatically How do you decide between local and distributed transactions? How do you decide between local and distributed transactions?  Local transaction are always faster (no DTC & fewer roundtrips)  Distributed transactions are required when your data lives in many RMs  Distributed transaction can make your designs and programming easier but they do so at the expense of response times and overall system throughput

46. Summary OLTP Concepts OLTP Concepts  The ACID rules  Isolation and locking  Writing local transactions Distributed Transactions Distributed Transactions  The transaction manager and two phase commit  The Distributed Transaction Coordinator  Writing distributed transactions MTS/COM+ Transactions MTS/COM+ Transactions  Creating objects inside a transaction  Controlling the transactions outcome