Embed Size (px)
Citation preview
1099Why Use InterBase?
Bill Todd
The Database Group, Inc.
Two Methods of Concurrency Control
Locking
Versioning
Locking SchemesYour locks restrict other user’s access to the
locked object
Lock granularity– Database– Table– Page– Row– Index
Pessimistic LockingRow is locked before you begin changing it.
Guarantees that you can commit your changes.
Locks can persist for a long time which reduces concurrency.
Larger number of locks increases load on database server.
Optimistic LockingMost common method among database servers.
Lock is placed when row is updated and released when transaction commits.
Locks exist for a shorter time.
Another user can update the row while you are making changes.
Optimistic Locking Example 1
John reads row and makes changes
Jane reads row and makes changes
John updates row causing lock
Jane attemps update & gets error
Optimistic Locking Example 2
John reads row and makes changes
Jane reads row and makes changes
John updates row causing lock
John commits releasing lock
Jane updates row overwriting John’s changes
Jane commits releasing lock
To Prevent Overwriting Changes
Use UPDATE statement with original value of all fields in WHERE clause– Does not work if only blob field is changed
Use UPDATE that includes timestamp or counter field in WHERE clause– Works for all field types
Transactions
All changes within a transaction succeed or fail as a single unit
Transaction Isolation Level
Your transaction’s isolation level controls when your transaction sees changes made by other transactions
SQL Standard Isolation Levels
Read uncommitted
Read committed
Repeatable read
Serializable
Locking & ConcurrencyRepeatable read isolation requires locks to stop
other users from updating rows you have read
Serializable requires locks to stop other users from updating rows you have read or inserting new rows
Locking ExampleInventory valuation by warehouse
– User A starts valuation query– User B moves material from warehouse 1 to
warehouse 20 while user A’s query is reading warehouse 10’s records
– User A’s query counts the material twice.
Solution
Use serializable isolation for the valuation query
Problem - User B cannot update rows until the valuation query ends
Versioning
Each transaction gets a unique number
Each row version contains the number of the transaction that created it
Versioning ExampleInventory valuation by warehouse
– User A starts valuation query– User B moves material from warehouse 1 to
warehouse 20 while user A’s query is reading warehouse 10’s records.
• Because there is an active transaction with a lower number new row versions are created for all rows that are updated
Versioning Example (continued)
User A’s transaction only reads the rows that were committed at the time it started
The transaction gets the correct count
User B is not blocked
Snapshot Isolation Level
Unique to InterBase
All the benefits of serializable
Does not place any locks
Does not block updates by others
How Versioning Works
When a snapshot transaction starts it gets:– The next transaction number– A copy of the Transaction Inventory
Pages (TIP)
The TIPShows the state of all transactions
– Active– Committed – Rolled back– Limbo
• Only occurs if a two-phase commit fails
Which Row Version is Read?
The most recent version whose transaction was committed at the time the reading transaction started is the version that is read
ExampleTransaction 90 reads a row with the following
versions
Tran 100 status = committed
Tran 80 status = active when reader started
Tran 60 status = rolled back
Tran 40 status = committed when reader started
How Locking & Versioning Compare
A series of examples
What happens with no concurrency control
What happens with locking
What happens with versioning
Example 1
Husband and wife go to two different ATM’s at the same time to withdraw money from their checking account.
Ex 1 – No Concurrency
Example 1 - Locking
Example 1 - Versioning
Ex 2 – No Concurrency
Example 2 - Locking
Example 2 - Versioning
Ex 3 – No Concurrency
Example 3 - locking
Example 3 - Versioning
Ex 4 – No ConcurrencySELECT with a WHERE clause
Another user inserts a row that satisfies the WHERE clause
Rerun the query and you see the new row
Example 4 - Locking
Place a table lock to prevent the insert
Place an index range lock to prevent the insert
Example 4 - Versioning
The insert is allowed
The second SELECT does not see the inserted row because its transaction number is higher than that of the reading transaction
Example 5
John and Jane are told to make their salaries equal
Ex 5 – No Concurrency
Example 5 - Locking
Example 5 - Versioning
Example 5 – Versioning Fix
How Do They Compare
Versioning provides better concurrency in most cases involving mixed reads and writes
RecoveryDatabase server must roll back all active
transactions on restart after a crash
For locking database this means processing transaction log
For versioning only the TIP must be updated– Status bits for all active transactions changed
from Active to Rolled Back– Garbage collection cleans up rolled back row
versions
Garbage CollectionRecord versions cause database to grow
Old versions are deleted each time a row is accessed
A sweep removes all row versions that are no longer needed
InterBase FeaturesTransaction support
– Read committed isolation– Snapshot isolation
• Benefits of serializable isolation without blocking updaters
– SQL 92 entry level support with extnesions– User define functions– Cost base query optimizer
InterBase FeaturesRow level locking
No lock escalation
No conversion deadlocks
Two phase commit
Multi-user and single user versions
SMP support
Hyperthreading support
InterBase FeaturesTriggers
– Before– After– Old & new values available– Multiple triggers per event– Control of trigger firing order– Post events to clients from triggers
Make any view updateable with triggers
InterBase FeaturesStored procedures
Temporary tables– ON COMMIT PRESERVE | DELETE– ALTER TABLE allows changing ON COMMIT
clause
Generators for incrementing keys
Null state for all data types
Declarative referential integrity
InterBase FeaturesServer level security
Database level security
The levels can be mixed on a single server
On-line backup
On-line metadata changes
Instantaneous crash recovery
Replication
InterBase FeaturesZero maintenance
Small disk footprint
Small memeory footprint
Does not require certified DBA
Does not require custom installer
Multi-platform support
IB vs. Oracle & DB2Much less expensive
Less complex – easier to learn
Easier to deploy
Does not require highly trained DBA
Much lower resource requirements– Memory– Disk– CPU
IB vs. Microsoft SQL ServerLess expensive
Less complex – easier to learn
Easier to deploy
No lock escalation
No conversion deadlocks
Does not require highly trained DBA
Lower resource requirements
Multi-platform support
Instant crash recovery
IB vs. Advantage & DBISAMSnapshot isolation for stable view of data without
blocking updates
On-line backups
Shadowing
Transactions can span databases
Triggers can post events to clients
Complex views are updateable with triggers
Applications Made For IBMixed long reads and updates
Embedded applications
Widely deployed applications
No on-site support
Multi-platform applications
Questions?
