...
/Detailed Design of Chubby: Part II
Detailed Design of Chubby: Part II
Let’s understand the locking service, how to handle the problems that occur in it, and how to perform operations in Chubby.
Data consistency and concurrency problems
Let’s assume that thousands of clients are trying to access the nodes in the primary replica and constantly reading data from them and also writing data into them. In such a scenario, Chubby will face the following data consistency and concurrency issues.
How will it ensure that only one client can write a file at a time?
What happens when clients are reading from a file, and a write request comes in and updates the data?
This lesson addresses the above-mentioned concerns in Chubby's design. The table below summarizes the goals of this lesson.
Lesson Summary
Section | Purpose |
Locking | This allows files of a server to be locked by clients in exclusive and shared modes, and addresses the issues mentioned above. |
Sequencer/lock delay | These methods provide support for the complexity of the primary replica getting delayed messages from clients that previously held a lock which is held by some other clients now. |
Events | This allows primary replica to report any changes in the database to the clients. |
API design of Chubby | This gives the commands that are used to perform several different operations in Chubby. |
Locking
Chubby's files and directories (nodes) can act as a reader or writer lock. Clients can hold these locks in exclusive and shared modes.
Numerous clients can hold a lock in reader mode (shared).
A single client handle can hold a lock in writer mode (exclusive).
Locks are advisory, meaning that holding a lock is not necessary to read a file, and it does not prevent other clients from reading that file. The clients accessing the files will have to cooperate to ensure no conflict occurs and locks are observed properly. Conflicts can occur only when other clients attempt to acquire the exclusive lock.
Why is advisory locking chosen over
Acquiring the lock in Chubby, either in exclusive or shared mode, requires write permissions. The write permissions ensure that an unprivileged reader (a reader not having a lock) cannot prevent a writer from making progress.
The write lock does make sense (only a single client can hold it), however, if numerous clients can hold a read lock and holding a lock is not even necessary for reading why do we have a read lock in Chubby?
Complexity in locking
Locking, when implemented in distributed systems, can be complex. The reason is that any client can request reading/writing to any node, so the processes can fail independently, and requests may get delayed and reach a primary replica server without any specific order. ...