Client-Server Caching James Wann April 4, 2000

Client-Server Architecture A client requests data or locks from a particular server The server in turn responds with the requested items Otherwise known as a data shipping architecture

Why Caching? Better utilizes the CPU and memory resources of clients Reduces reliance on the server Increases the scalability of the system

Disadvantages of Caching Increased network utilization Extra load on system Increased transaction abort rates, depending on algorithm

Test Workloads for Caching Algorithms HOTCOLD – There is a high probability that pages in the “hot set” will be read. However, there is equal probability that pages in either the “hot set” or “cold set” will be written FEED – There is one client that writes to pages in the “hot set”. The other clients have a high probability of reading from the “hot set”

Test Workloads for Caching Algorithms (cont’d) UNIFORM – All pages have equal probability of being either read or written HICON – There is a high probability of conflicts in reading/writing

Server-Based Two-Phase Locking Client transactions must obtain locks from the server before accessing a data item Easiest algorithm to implement Heavy messaging overhead Best for workloads with high data contention

Optimistic Two-Phase Locking Each client has its own lock manager Upon commit, the client sends a message to the server stating which pages are updated The server sends an update message to all clients with copies of the pages The next action depends on algorithm

clientserver client Commit Phase

clientserver client Update Message Phase

Non-Dynamic O2PL Algorithms O2PL-Invalidate (O2PL-I) – invalidates the updated pages in the clients receiving the message O2PL-Propagate (O2PL-P) – propagates the changed pages to the clients that already have the pages

Dynamic O2PL Algorithms O2PL-Dynamic (O2PL-D) – chooses between propagation and invalidation based on a certain criteria Criteria 1 – The page is at the client where the message is being sent Criteria 2 – The page was previously propagated to the client and it has since been reaccessed

Dynamic O2PL Algorithms (cont’d) O2PL-New Dynamic (O2PL-ND) – uses the same criteria as O2PL-D with one additional characteristic: A structure called the invalidate window is used hold the last n invalidated pages Most recently invalidated pages are placed in front of the window

Dynamic O2PL Algorithms (cont’d) If a page is accessed and its number is found in the invalidate window, then the entry is marked as being a mistaken invalidation Criteria 3 – The page was found to be previously invalidated by mistake

Evaluation of O2PL Algorithms (HOTCOLD) O2PL-I and O2PL-ND have a higher throughput than O2PL-P and O2PL-D This is due to the fact that propagated updates may not necessarily be accessed again (wasted propagations) O2PL-I, O2PL-D, and O2PL-ND have similar performance on a faster network

Evaluation of O2PL Algorithms (FEED) O2PL-P, O2PL-D, and O2PL-ND have better throughput than O2PL-I This scenario benefits propagation (keeps “hot pages” in buffer) However, the performances are comparable in small buffers

Evaluation of O2PL Algorithms (UNIFORM) O2PL-P and O2PL-D have far less throughput than the other algorithms Higher probability of wasted propagations

Figures 1 through 6 in paper

Callback Locking Allows caching of data pages and locks Clients obtain locks by making a request to the server If there is a lock conflict, clients with the locks are asked to release the locks The lock request is granted only when all the locks are released

CB-Read Only read locks are cached When a write lock request is made, the server requests all clients with the specified page to release the page If all clients comply, then a write lock is granted All subsequent lock requests are blocked until the write lock is released

CB-All Both locks are cached and write locks are not released at the end of a transaction A page copy at a certain client is designated as the exclusive copy Upon a read request from another client, then exclusive copy is received and the original client no longer has the exclusive copy This is called a downgrade request

Evaluation of Callback Algorithms (HOTCOLD) O2PL-ND has better throughput than the Callback algorithms The Callback algorithms require more messages per transaction However, the throughput difference is not significant

Evaluation of Callback Algorithms (FEED) O2PL-ND has better throughput than either Callback algorithms This is because the pages are usually already found in the clients in O2PL-ND and so no extra messages are needed Again, the performance difference is not significant

Evaluation of Callback Algorithms (UNIFORM) All three algorithms have similar throughput

Evaluation of Callback Algorithms (HICON) O2PL-ND performance suffers because of frequent aborts due to late deadlock- detection CB-Read has higher throughput than CB-All because of smaller messaging requirements

Figures 8 through 13 in paper

Figures 14 through 15 in paper

Conclusion O2PL-ND proves to be a more flexible algorithm than O2PL-D Invalidation is the default, rather than propagation Ideal for a small number of clients

Conclusion (cont’d) CB-Read is a more adaptable algorithm than O2PL-ND and CB-All Detects deadlock earlier than O2PL-ND and avoids aborts for long transactions Has lower messaging overhead than CB-All Server-based 2PL works best with a large number of clients in a high-contention situation. Perhaps further research should be done in consideration of faster LANs (e.g. fast ethernet)?