Fundamentals of Databases Client-Server Databases

Fundamentals of Databases: Client-Server Databases Database Servers Databases provide a simple function Allow storage and access of data As such, databases have a very wide range of uses Used in websites to store user account information Used in schools to store class and scheduling information Used in companies to store employee information More often than not though, these databases will be found on a server Fundamentals of Databases: Client-Server Databases

Fundamentals of Databases: Client-Server Databases Database Servers Servers are devices (on a network) that provide some form of access HTTP servers allow websites to be stored and accessed FTP servers allow files to be stored and accessed remotely Databases can be stored on a server as well Usually referred to as SQL Servers Allows for Other servers to access them (like HTTP servers) Concurrent access (multiple requests handled at once) Fundamentals of Databases: Client-Server Databases

Fundamentals of Databases: Client-Server Databases Database Servers These SQL Servers can be accessed in two ways Via clients (e.g. phpMyAdmin, Office Access) Via requests (SQL) Clients have lots of tools built in for handling data in a database Creating tables Inserting records Deleting tables/records Fundamentals of Databases: Client-Server Databases

Fundamentals of Databases: Client-Server Databases Database Servers Databases can be accessed outside of clients using SQL instructions Structured Query Language SQL, however, is just an instruction set A series of possible commands Something needs to send those commands to the server Lots of programming languages have SQL instructions built into their language Can then send the instructions to the database via HTTP Fundamentals of Databases: Client-Server Databases

Fundamentals of Databases: Client-Server Databases Concurrent Access There is a big problem with allowing concurrent access Two requests could impact the same data Same record Same table For example, one request could retrieve data from a record Another request could delete that record If they happen at the same time, the record could be deleted before it is retrieved Leading to incomplete data retrieval Fundamentals of Databases: Client-Server Databases

Fundamentals of Databases: Client-Server Databases Concurrent Access Most databases have systems built in to stop this Usually enabled by default Some database systems allow these to be toggled The following are systems that can alleviate this concurrent access problem Record Locks Serialisation Timestamp Ordering Commitment Ordering Fundamentals of Databases: Client-Server Databases

Fundamentals of Databases: Client-Server Databases Concurrent Access Record Locking Records can be viewed, deleted, or updated Records being individual ‘entities’ in a table When a record is being edited, it can be locked This means no other request can ‘touch’ that record while it is still locked The lock can block all access, or only update/delete requests The database logs where the edit request came from and locks the requested record from other requests When the request is finished, the database unlocks the record Fundamentals of Databases: Client-Server Databases

Fundamentals of Databases: Client-Server Databases Concurrent Access Serialisation Rather than trying to handle multiple requests at once (parallel) We can tell the database to handle them one-after-the-other This is serial Imagine one request is editing a record and another request is deleting a record In parallel, this could be a problem In serial, the second request has to wait before the other request is complete The database can use this by default Or, some programming languages let us send instructions in serial (Node.JS ‘sqlite’) Fundamentals of Databases: Client-Server Databases

Fundamentals of Databases: Client-Server Databases Concurrent Access Timestamp Ordering Where every request sent to the database has a timestamp attached to it A unique value that represents the time the request was received Requests can be received in parallel (Optional) A unique ID counter is incremented and used along with the timestamp If two requests received at the exact same time Requests are then handled in serial Order based on timestamp Later requests (greater timestamps) dealt with after earlier (smaller) ones Fundamentals of Databases: Client-Server Databases

Fundamentals of Databases: Client-Server Databases Concurrent Access Commitment Ordering Was theorised to solve the problem of global serialisability Making a multidatabase serial as a whole Each sub-database has its own serial request schedule The database as a whole will handle these serial requests seemingly in parallel Commitment ordering acts as an add-on to any other non-blocking concurrent access solution (like timestamp ordering) However, this one focuses on ordering requests that conflict when comitted Used in a distributed database system such as mobile device client-server systems where transactions are created locally on the mobile device before being sent to the server for execution. The transactions are scheduled at the server so that they are committed in an order that avoids concurrency conflicts. Fundamentals of Databases: Client-Server Databases

Fundamentals of Databases: Client-Server Databases Concurrent Access Commitment Ordering Here is the technical definition for this property: “Let 𝑇 1 , 𝑇 2 be two committed transactions in a schedule, such that 𝑇 2 is in conflict with 𝑇 1 ( 𝑇 1 precedes 𝑇 2 ). The schedule has the Commitment ordering (CO) property, if for every two such transactions 𝑇 1 commits before 𝑇 2 commits.” This is not a system to use (per se), but something that is achieved Fundamentals of Databases: Client-Server Databases