lazy modular upgrades in persistent object stores
DESCRIPTION
Lazy Modular Upgrades in Persistent Object Stores. Chandrasekhar Boyapati, Barbara Liskov , Liuba Shrira, Chuang-Hue Moh, Steven Richman MIT CSAIL October 2003. Persistent Object Store. Stores objects with methods Objects belong to classes Classes implement types. Persistent Root. - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/1.jpg)
Lazy Modular Upgrades in Persistent Object Stores
Chandrasekhar Boyapati, Barbara Liskov, Liuba Shrira, Chuang-Hue Moh, Steven Richman
MIT CSAILOctober 2003
![Page 2: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/2.jpg)
Persistent Object Store
• Stores objects with methods– Objects belong to classes– Classes implement types
Persistent RootPersistent Root
![Page 3: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/3.jpg)
Transactions
• Objects are accessed within transactions– Transactions mask concurrency and failures
Persistent RootPersistent Root
Client 1
Client 2
![Page 4: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/4.jpg)
Upgrades
• Upgrades are needed to– Correct errors– Improve performance– Meet changing requirements
![Page 5: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/5.jpg)
Outline
• Defining upgrades• Upgrade execution• Upgrade modularity conditions• Performance
![Page 6: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/6.jpg)
Defining Upgrades
• Upgrade must preserve persistent state– E.g., set implementation changes from
vector to hash table
• A class-upgrade is <old-class, new-class, TF>
• TF: old-class new-class– TF changes representation of objects– System preserves identity
![Page 7: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/7.jpg)
Completeness
• Upgrades can be – Compatible– Incompatible
• An upgrade is a set of class-upgrades – must contain all class-upgrades needed to
maintain type correctness
![Page 8: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/8.jpg)
System executes Upgrades
• Requires transforming all old-class objects
• Goal: don’t interfere with applications– Don’t stop the world
• Goal: be efficient in space and time– Don’t copy the database or use versions
• Goal: be expressive– Don’t limit expressive power of TFs
![Page 9: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/9.jpg)
Solution: Lazy, Just in Time
• Applications continue to run– Objects are transformed just before first use
• Later upgrades run in parallel with earlier ones– If x has two pending transforms, they run in
upgrade order
![Page 10: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/10.jpg)
How System Works
• When application accesses x– Interrupt the application– Run earliest pending transform for x– Each transform runs in its own transaction
• Application continues after transform commits
• Transforms can be interrupted too
![Page 11: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/11.jpg)
Example
…; U1; … TF(x); A1; … TF(y); A2; … U1 is installed A1 starts to run, accesses x TF(x) runs and commits A1 continues and commits A2 starts to run, accesses y TF(y) runs and commits A2 continues and commits
![Page 12: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/12.jpg)
Example …; U1; … TF(x); A1; … TF(y); A2; … U1 is installed A1 starts to run, accesses x TF(x) runs and commits A1 continues and commits A2 starts to run, accesses y TF(y) runs and commits A2 continues and commits
Problem: suppose TF(y) accesses x
![Page 13: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/13.jpg)
Modular Reasoning
• Want to support modular reasoning:– Programmer can reason about TF as if it were
an extra method of the old-class– Programmer can assume same old-class
interfaces and invariants
XTF
![Page 14: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/14.jpg)
Desired Semantics
• Upgrades appear to run when installed– Serialized before all later application
transactions• Upgrades appear to run in upgrade order• Within an upgrade, transforms run as if
each was the first to run
![Page 15: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/15.jpg)
Order within an Upgrade
• Consider x and y due to be upgraded
• If TF(y) uses x (transitively) then if [TF(x); TF(y)], this must have same effect as [TF(y); TF(x)]
Y X
![Page 16: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/16.jpg)
Ensuring Correct Behavior
• Based on encapsulation: An object must encapsulate every object it depends on
• A TF is well-behaved if it uses only encapsulated sub-objects
X
![Page 17: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/17.jpg)
Approach • Analyze TFs• Usually they will be well-behaved• Otherwise notify user
– User can use triggers to control order– Or, we maintain versions
Z
X Y
![Page 18: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/18.jpg)
Performance
• Implemented in Thor• Analyzed overhead
FE
Clients
OR OR
FE
App App
![Page 19: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/19.jpg)
Baseline Overhead
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
0.2
T1 T2b
Traversal
Ela
psed
Tim
e (s
)
ThorBase Full ROTThorUpgrades Full ROTThorBase Empty ROTThorUpgrades Empty ROT
![Page 20: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/20.jpg)
Transform Overhead
Time per object (μs) T1 T2b
Transform 11.3 11.5
Commit 19.9 1.0
![Page 21: Lazy Modular Upgrades in Persistent Object Stores](https://reader035.vdocument.in/reader035/viewer/2022062315/56815d82550346895dcb9095/html5/thumbnails/21.jpg)
Conclusions
• Correctness conditions for any upgrade system– Support modular reasoning
• Our lazy implementation approach– Correct and efficient
• Future work: upgrades in distributed systems