ABSTRACT

Oracle first implemented multiversioning, which was called "read consistency", in Version 4 (ca. 1983) of the kernel. It supported the old master/new master programming paradigm for both application builders and query-processor implementors while avoiding the reader/writer serialization that results from using automatic share locks. The resulting transaction consistency model was arcane, not exactly serializable, but pragmatic in actual use. In this session, Mr. Bamford will cover read consistency from a number of viewpoints. First, the model will be described and a little detail about Oracle's current implementation will be given. Next, the consequences of having read consistency as part of the database's core architecture will be discussed. In particular, the effects on the designs for row locking, query processing, distributed query, distributed cache coherence, referential integrity, and set updates will be described. This will be fol- lowed by a comparison of Oracle's read consistency model to other common concurrency models, looking at cost and throughput under a variety of workloads. Finally, Mr. Bamford will propose how Oracle intends to carry read consistency into the future as support is added for complex objects, distributed com- putations, and long transactions.