Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
A to Mi City

A to Mi City

Ratings: (0)|Views: 9|Likes:
Published by parn_sharma9226

More info:

Published by: parn_sharma9226 on Jul 27, 2009
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PPT, PDF, TXT or read online from Scribd
See more
See less





page 107/27/09CSE 30341: Operating Systems Principles
6.9: Atomic Transactions
Introduce notions of databases into operatingsystems
Challenge is that some of these operations are “heavy”and not necessarily fast
A collection of operations that performs a single logicalfunction. For example, changing the state and moving theprocess from waiting to ready state is one transaction
Transactions are atomic withall or nothingsemantics
Committed transactions means, all the operations wentthrough
Aborted transactions means, none of them went through
You cannot be in a middle state, e.g., changed state,removed it from waiting state but didn’t add to ready state
When a transaction aborts, we roll back
page 207/27/09CSE 30341: Operating Systems Principles
Storage states
Storage to implement transactions:
Volatile storage: Does not survive system crash
Nonvolatile storage: Survives system crashes
Stable storage: Information is “never” lost. Usesnonvolatile storage and replication
Log-based recovery:
Write-ahead logging, where we write all operations into alog in stable storage
<transaction name, data item name, old value, new value>
Transaction is made up of 
<Ti, starts> set of transaction logs <Ti, commit>
If both starts and commit is there, then the transaction iscommitted. Else, it is rolled back
Logs are idempotent, you can apply it again and again inthe same order without side effects
page 307/27/09CSE 30341: Operating Systems Principles
Logs keep growing. After every failure, we’d haveto go back and replay the log. This can be timeconsuming.
Checkpoint frequently
Output all log records currently in volatile storage ontostable storage
Output all modified data residing in volatile storage to thestable storage
Output a log record <checkpoint> into stable storage
On failure, search backwards till we hit the firstcheckpoint. The first transaction start from thecheckpoint (going back) is the start of replay

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->