How MTS Makes Your Life Easier

1
How MTS Makes Your Life Easier

• Rob Macdonald
• Salterton Hill Ltd
• rob_at_salterton.com

2
Objectives

• To explain what Microsoft Transaction Server
  really does
• To see why using MTS makes sense
• Persuade you that MTS is really your cozy,
  fun-loving friend
• Introduce COM

3
Whats in a Name?

• MTS 2.0 was released as part of the NT4 Option
  Pack
• Required by IIS 4
• There is NO MTS in Windows 2000
• MTS becomes COM Component Services
• An MTS Package becomes a COM Application

4
Agenda

• What does Scalability mean and how does MTS
  achieve it?
• A Question of State
• Transaction Management and MTS

5
Who Am I?

• Nine years running a Windows/client-server
  software house
• Two years as an independent software specialist
• Author of RDO/ODBC/ADO/COM/COM books and
  articles
• Trainer

6
Scalability

• Scalability can mean a number of things
• An applications ability to handle more data or
  objects
• A multi-user applications ability to handle more
  concurrent users
• To Microsoft, scalability almost always means
  large numbers of users

7
What affects Scalability?

• Processor and Storage/Memory Load
• roughly linear increase
• throw hardware at it works up to a limit
• Connections
• classic dilemma to hold or not to hold
• pooling provides (promises?) a solution
• Threads
• managing large number of threads consumes server
  resources context switching
• Locks
• no solution can only minimise impact

8
MTS Makes Life Easier Processor and
Storage/Memory Load
DB server
Web/App server
As you scale, single box solution will eventually
become impractical
9
MTS Makes Life Easier Processor and
Storage/Memory Load

• Moving to a multi-server environment can require
  a re-write
• how are you going to handle code migration?
• how are you going to handle transactions?
• 'logical units of work'
• MTS handles this painlessly
• Import/Export Packages/Application
• Distributed Transaction Co-ordinator
• More later

10
MTS Makes Life Easier Processor and
Storage/Memory Load

• Implications for ASP
• Place as much functionality in COM components as
  possible
• And as little as possible in ASP
• COM objects are easier to migrate and distribute
• Recommended practice anyway
• Let MTS handle transactions for you
• Instead of ADO Connection objects TX methods
• BeginTrans, CommitTrans, RollBackTrans
• co-ordinates transactions across multiple servers

11
MTS Makes Life Easier Connections

• Pooling solves the connection dilemma
• There are three levels at which database
  connection pooling can apply
• ODBC
• OLE DB
• Transaction Server

12
MTS Makes Life Easier Connections

• There are some common ways to make sure pooling
  doesnt work for you
• Keep open multiple connections and connected
  Recordsets
• Fail to explicitly Close ADO resources
• Insist on using many different logon contexts
• Fail to keep one connection open per logon
  context
• Without using MTS, this will destroy the
  connection pool
• Not an issue with ASP as MTS is always there

13
MTS Makes Life Easier Connections

• Implications for ASP
• Exploit the ability of MTS to work with ODBC or
  OLE DB pooling
• dont hold on to ADO Connection objects
• (eg in Session or Application objects)
• do Close and Set Nothing for each Connection
• do restrict the number of logon contexts used in
  the application
• preferably to 1
• can always use MTS Security

14
MTS Makes Life Easier Threads

• Threads are the basic unit of execution in
  Windows programs
• Each process uses at least one thread
• CPU time is shared between threads
• VB objects and scripts run on one thread only
• Other system resources are free-threaded or
  thread-neutral

technically, they are Single Threaded Apartment
(STA) components
15
MTS Makes Life Easier Threads
Consider an n-tier VB Application
Each user requires a thread, a server object and
all its resources to be maintained
Even though lt5 of server resources are in use at
any one time
16
MTS Makes Life Easier Threads
MTS supplies ObjectContext object and context
wrapper to intercept client calls
Client remains connected to context wrapper at
all times
Server object and all its resources are
deactivated
MTS
Thread is returned to thread pool
interceptors are a key concept in COM
17
De-activated Whats that exactly?

• In NT4 / MTS 2, de-activated is a euphemism
  for completely destroyed
• In W2000 / COM, de-activated objects can be
  pooled if they use an appropriate threading model
• VB6 doesnt
• Unlike thread pooling, object pooling is no big
  deal
• objects are usually the tiniest resource you
  consume, even if they are the most visible

euphemism is a euphemism for balony
18
De-activated When does it happen?

• Only when the server wants it to
• MTS /COM provides two special methods to trigger
  de-eactivation
• For high scalability, servers should de-activate
  as often as possible
• But its not mandatory to do it after each client
  call

GetObjectContext.SetComplete GetObjectContext.SetA
bort
19
MTS Makes Life Easier Threads

• Implications for ASP
• Avoid using resource consuming Session objects
  where at all possible
• easier said than done
• Microsoft recommend it for high scalability
• discuss state management later
• If Session objects cant be avoided
• de-activate VB objects stored for Session as
  often as possible
• go for short Session time-outs

20
MTS Makes Life Easier Locks

• Scalability is about avoiding bottlenecks
• most scalability issues are largely about
  performance
• Lock management is about a different kind of
  bottleneck
• its essential to lock resources to ensure
  consistent results
• eg during transactions
• it's easy to forget about locks - but they are
  very expensive
• its all too easy to keep records/pages locked
  longer than necessary
• resulting in costly time-outs

21
MTS Makes Life Easier Locks

• MTS minimises locking issues by encouraging
  frequent de-activation
• SetComplete and SetAbort define an objects
  transaction boundaries as well as its activation
• ensures database resources get released
• MTS detects and resolves deadlocks without
  waiting for a timeout
• Enhances performance and scalability

22
A Question of State

• HTTP is inherently stateless
• ASP addresses this issue by defining Session
  objects
• Microsoft advise against using Session objects
  if scalability is your goal
• Objects are traditionally stateful
• Contain properties that define state
• MTS de-activation and transaction model encourage
  stateless objects

23
Whats going on here?

• The Good News
• Both HTTP and MTS are stateless models of
  computing
• This means they understand each other !
• The BAD News ..
• Applications obviously need state
• To achieve scalability, you need to treat state
  as a big deal
• Hold it somewhere that doesnt tie up unscalable
  resources

24
Where to put State?
At the client (eg, Web page arguments, cookies
etc)
In the database (eg, Session Management tables)
Web/App server
In server objects (eg, Session object, VB objects)
In Server State Management tools (eg, Shared
Property Manager, IMDB, Personalisation Servers)
25
StateAt the Client

• Highly Scalable
• application load distributed on 'per user' basis
• Increases network traffic
• Adds complexity to client

TECHNIQUES
Use context / state arguments in all client
interactions Create temporary file on client (ie
cookie) (assuming server permits this)
26
StateIn Server Objects

• Easy
• Always consumes more resources than necessary
• Becomes prohibitive when objects can only run on
  one thread (eg VB objects)

TECHNIQUES
Session Object Data and Objects stored in Session
Object
27
StateIn the Database

• Databases are designed to serve data in highly
  concurrent environments
• SQLServer, Oracle, Sybase etc (not Access)
• May involve unwanted disk / network round trips
  for highly volatile, non-critical data

TECHNIQUES
Create Session Management tables and wrap with
code Consider using W2000 In Memory DataBase
(IMDB)
28
StateIn Server State Management tools

• Tools designed for this purpose
• Requires adopting new programming model
• Can place large demands on RAM

TECHNIQUES
MTS Shared Property Manager Personalisation
Services W2000 In Memory DataBase (IMDB) VB
Objects and Recordsets can be persisted and
stored with no threading issues
29
State Management Summary

• State Management is NOT an MTS issue
• it's a scalability issue
• objects stored in Session state work only for a
  small, known upper limit of concurrent users
• MTS helps you think explicitly about state
• in the same way that COM helps you think about
  interfaces

30
Transaction Management and MTS

• Transaction
• A Logical Unit of Work
• Required to keep data consistent
• Provides a stateless programming model that
  doesn't depend on a persistent connection
• Puts the 'T' in MTS

31
Transaction Management and MTS

• In MTS, transactions happen outside databases
• MTS manages 'Component Transactions' across
  multiple MTS servers
• databases are merely enlisted to do their part of
  the work
• MSMQ is also an MTS 'Resource Manager'

A Resource Manager is any server that can
manage its own transactions and implements an MTS
compliant transaction protocol, such as XA or OLE
Transactions
32
For Example ...
DB server
A
A
B
B
Component A is marked as 'Requires New
Transaction' Component B is marked as 'Requires a
Transaction' Other options are 'Supports
Transactions' and 'Does not Support Transactions'
Components are marked for transactions either
using MTS Explorer, or using an ASP directive, or
by setting the MTSTransactionMode property on a
VB6 class
33
Code For Component A
On Error Goto ErrH Dim cn As New Connection Dim
oContext as ObjectContext Dim objB as B Set
oContext GetObjectContext cn.Open
ltUDL1gt cn.Execute ltupdate table Agt Set objB
oContext.CreateInstance(ltProgID for
Bgt) objB.DoWork oContext.SetComplete Exit
Sub ErrH oContext.SetAbort End Sub
Get A's context
Do some database work
Create B in the same transactional context
Decide transactional outcome of A's work
34
Code For Component B
Sub DoWork On Error Goto ErrH Dim cn As New
Connection Dim oContext as ObjectContext Set
oContext GetObjectContext cn.Open
ltUDL2gt cn.Execute ltupdate table
Bgt oContext.SetComplete Exit Sub ErrH oContext.S
etAbort End Sub
Get B's context
Do some database work
Decide transactional outcome of B's work
B can run in its own transactional context, or
that of its caller
35
Distributed Transactions
Any of these configurations can be supported
using the same code base
36
Summary

• We have explored
• Scalability and how MTS achieves it
• State and how to manage it
• distributed transactions
• MTS makes life easier
• if you want to take on the scalability challenge
• 'MTS is the future of COM'
• or at least, a big part of it