Scribd
Upload
3 views12 pages

Managing Replicated Objects: Deterministic Thread Scheduling

Uploaded by

ossamasamir.workout
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
3 views12 pages

Managing Replicated Objects: Deterministic Thread Scheduling

Uploaded by

ossamasamir.workout
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 12

Managing replicated objects

Prevent concurrent execution of multiple invocations on the same object:


access to the internal data of an object has to be serialized. Using local
locking mechanisms are sufficient.
Ensure that all changes to the replicated state of the object are the same:
no two independent method invocations take place on different replicas at
the same time: we need deterministic thread scheduling.
Replicated-object invocations
Problem when invocating a replicated object
Replicated-object invocations

Forwarding a request Returning the reply


Primary-based protocols
Primary-backup protocol

Example primary-backup protocol


Traditionally applied in distributed databases and file systems that require a high degree
of fault tolerance. Replicas are often placed on the same LAN.
Replicated-write protocols
Quorum-based protocols
Assume N replicas. Ensure that each operation is carried out in such a way that a
majority vote is established: distinguish read quorum NR and write quorum NW . Ensure:
1. NR + NW > N (prevent read-write conflicts)
2. NW > N/2 (prevent write-write conflicts)

Correct Write-write Correct (ROWA)


conflict
Continuous consistency: Numerical errors

Principal operation
Every server Si has a log, denoted as Li .
Consider a data item x and let val (W ) denote the
numerical change in its value after a write operation W .
Assume that
∀W : val (W ) > 0

W is initially forwarded to one of the N replicas,


denoted as origin(W ). TW [i, j ] are the writes executed
by server Si that originated from Sj :

TW [i, j ] = ∑{val (W )|origin(W ) = Sj & W ∈ Li }


Implementing client-centric consistency
Keeping it simple
Each write operation W is assigned a globally unique identifier by its origin server. For each
client, we keep track of two sets of writes:
Read set: the (identifiers of the) writes relevant for that client’s read operations
Write set: the (identifiers of the) client’s write operations.

Monotonic-read consistency
When client C wants to read at server S, C passes its read set. S can pull in any updates before
executing the read operation, after which the read set is updated.
Monotonic-write consistency
When client C wants to write at server S, C passes its write set. S can pull in any updates,
executes them in the correct order, and then executes the write operation, after which the write set
is updated.
Implementing client-centric consistency

Read-your-writes consistency
When client C wants to read at server S, C passes its write set. S can
pull in any updates before executing the read operation, after which the
read set is updated.
Writes-follows-reads consistency
When client C wants to write at server S, C passes its read set. S can
pull in any updates, executes them in the correct order, and then
executes the write operation, after which the write set is updated.
Example: replication in the Web
Client-side caches
In the browser
At a client’s site, notably through a Web proxy

Caches at ISPs
Internet Service Providers also place caches to (1) reduce
cross-ISP traffic and (2) improve client-side performance. May
get nasty when a request needs to pass many ISPs.
Cooperative caching
Web-cache consistency
How to guarantee freshness?
To prevent that stale information is returned to a client:
Option 1: let the cache contact the original server to see if content is
still up to date.
Option 2: Assign an expiration time Texpire that depends on how long
ago the document was last modified when it is cached. If Tlast modified is
the last modification time of a document (as recorded by its owner),
and Tcached is the time it was cached, then

Texpire = α(Tcached −T ast modified) + Tcached


l

with α = 0.2. Until Texpire, the document is considered valid.


Alternatives for caching and replication

Database copy: the edge has the same as the origin server
Content-aware cache: check if a (normal query) can be answered with cached data. Requires
that the server knows about which data is cached at the edge.
Content-blind cache: store a query, and its result. When the exact same query is issued
again, return the result from the cache.

You might also like