Atomicity - E-Commerce - Lecture Slides, Slides of Fundamentals of E-Commerce

Download Atomicity - E-Commerce - Lecture Slides and more Slides Fundamentals of E-Commerce in PDF only on Docsity!

2. Atomicity & Durability

Using Shadow Paging

Transaction Processing

for E-Commerce

Introduction

To get started on the Java-C# project, you needto implement atomicity and durability in acentralized resource manager (i.e. a database).

The recommended approach is

shadowing.

This section provides a quick introduction.

A more thorough explanation of the overalltopic of database recovery will be presented in acouple of weeks.

Shadowing in a Nutshell

The database is a tree whose

root

is a single disk block

There are two copies of the tree, the

master

and

shadow

The root points to the master copy

Updates are applied to the shadow copy

To install the updates, overwrite the root so it points tothe shadow, thereby swapping the master and shadow

Before writing the root, none of the transaction’s updates arepart of the disk-resident database

After writing the root, all of the transaction’s updates are partof the disk-resident database

Which means the transaction is atomic and durable

More Specifically …

The

database

consists of a

set of files

Each file consists of a

page table

P

and

a

set of pages

that P points to.

A

master page

points to each file’s

master page table

Assume transactions run serially. I.e., at mostone transaction runs at any given time.

Assume that for each page table thetransaction has a private shadow copy in main-memory.

To Write a Page P

i

Transaction writes a shadow copy of page P

i^

to

disk (i.e. does not overwrite the master copy).

Transaction updates its page table to point tothe shadow copy of P

i

Transaction marks P

’s entry in the page tablei

(to remember which pages were updated)

After Writing Page P2b

Pt

T

[a]^123 ... Pt

T

[b]^123 ...

a b

P1a

Pt

1

[a] 1 2 3 ... Pt

1

[b] 1 2 3 ...

P2a P1b P2bOld

Initial State

D I S K

Main

Memory

For T

Master

P2bNew

What if the System Fails?

Main memory is lost

The current transaction is effectively aborted

But the database is still consistent

To Commit

Pt

T

[a]^123 ... Pt

T

[b]^123 ...

a b

P1aOld

Pt

1

[a] 1 2 3 ... Pt

1

[b] 1 2 3 ...

P2a P1b P2bOld

Initial State

D I S K

Master

P2bNew P1aNew

1. First copy Pt

T

[a] and Pt

T

[b] to disk

Shadow Paging with Shared Files

What if two transactions update different pages of a file?

If they share their main-memory shadow copy of the pagetable,then committing one will commit the other’s updates too!

One solution: File-grained locking (but poor concurrency)

Better solution: use a private shadow-copy of each pagetable, per transaction. To commit T, do the following within a critical section

For each file F modified by T

get a private copy C of the last committed value of F’s pagetable

update C’s entries for pages modified by T

store C on disk

Write a new master record, which swaps page tables for thefiles updated by T, thereby installing just T’s updates

Managing Available Disk Space

Treat the list of available pages like another file

The master record points to the master list

When a transaction allocates a page, update itsshadow list

When a transaction commits, write a shadowcopy of the list to disk

Committing the transaction swaps the masterlist and the shadow

Your Project

You need not use the exact data structure presentedhere.

In particular, you don’t necessarily need a pageabstraction.

There are design tradeoffs for you to figure out.