Skip to main content
Department of Information Technology

Project: Transactions and Concurrency Control

In this project, you will put your knowledge on concurrency control to use by implementing a real transaction manager.

Important:
The project is to be done in pairs. If you for some reason want to do it individually, you must first ask Cong Quy Trinh. General discussions with other course mates is ok, but the solution handed in must be produced by the group.

Description

We consider a distributed systems with a server-client architecture, where the server controls a database (or a store) and the clients run some transactions on the database indirectly via communication with the server.
For the sake of simplicity we assume the following:

  • The store handles 4 global variables a, b, c and d
  • A transaction is a list of read and write operations of the form [{read, a}, {write, b, 200}, {read, d}, {write , c, 100}].

The processes (clients and servers) are supposed to run on different Erlang nodes. The clients are supposed to communicate with the server which is maintaining the store. The store is not visible to the clients. Only the server is visible. The clients are supposed to establish connection and then send transaction requests to the server, which in turn tells the
client whether the request was committed or aborted.

Client Side Software

The client process provides a graphical interface in which the user can manually enter transactions. Internally, the client spawns a process handler. The handler starts a window and tries to establish a connection to the server by spawning a connector process. Once the connection is established, the user may enter a sequence of actions which will be collected by the handler.
When the user enters the run command, the handler will send the transaction to the server and wait for a reply. The user will only get back the message abort or commit, and is then free to either run the transaction again or reset it and enter a new one.
The modules that implement the client are in the files: client.erl, parser.erl and window.erl

Server Side Software

The server receives message from the different clients and takes the proper actions towards the store. More precisely, the server spawns a registered process under the name transaction_server which does the following:

  • First it spawns a store process which maintains a list of variables [{a,0},{b,0},{c,0},{d,0}] (evaluating the function store_loop()).
  • Then it evaluates the function server_loop() which is supposed to maintain connection to the clients and controls the store process.

The module implementing the server is in the file server.erl.


Don't panic!
Everything will become clear once you run the system.


Starting the System

  • Download the following skeleton, extract it and compile it:

>tar xvfz project.tar.gz
>cd Project
>make

This will generate all the .beam files.

  • Now open different terminals and enter the directory where you compiled the skeleton (in each one of them).
  • In each terminal, start an Erlang node using the same cookie. For example:
  • terminal 1

>erl -name client_1 -setcookie abc

  • terminal 2

>erl -name client_2 -setcookie abc

  • terminal 3

>erl -name server -setcookie abc

  • Start a transaction server in terminal 3

>server:start().

  • Start 2 clients in the remaining terminals. Observe that in order to start the client you need to specify the name of the node where the transaction server is running. For example if it is running on the Erlang node 'server@machinename.it.uu.se', then start the clients as follows:

>client:start('server@machinename.it.uu.se').

  • It is not necessary that these applications are running on the same machine. For instance you can start the Erlang nodes on different machines. Below, we give an example of how you start a client on a remote machine:
    • Establish an ssh connection in terminal 1

>ssh -X yourlogin@hamberg.it.uu.se 
>password: (you will be asked to provide your password)

  • Enter the directory where you compiled the skeleton and start an Erlang node and a client as described above. In such a case, you will end up with a client running on hamberg, while the server and the remaining client are running on the local machine (the lab terminal server or whatever).

Important:
There are no guarantees that this will work in case (for example) you start a client at home and the server in one of the university machines (probable firewall issues). This will work properly if you start all the Erlang nodes on the different machines available at the university campus.


Before starting with the task, you should:

  • Examine the description of the transaction language given in the file parser.erl and experiment by entering some actions in the client window. Try to understand what happens and how the server responds.
  • Look at what the server does internally in server.erl

Important:
In particular, note that:

  • The order in which the transaction actions are sent is preserved at the server side.
  • A transaction is always marked by the message request at the start, and confirm at the end.

Task

Choose and implement a strategy for concurrency control of the transactions.

In your choice of strategy you should address:

  • Atomicity: A transaction is a all or nothing
  • Isolation: The result of concurrent transactions is equal to the result of the transactions executed sequentially (in a certain order).
  • Concurrency

Examples of strategies:

  • Two-phase locking
  • Timestamps
  • Optimistic concurrency control

In choosing strategy, efficiency is also important. Solutions that cause unnecessary delays will not be accepted.

When implementing, you are supposed to follow these guidelines:

  • You are not supposed to change any client module besides minor modifications needed for some control strategies (e.g. timestamps).
  • You are free to modify the server file but be careful when you are modifying the start() function.
  • When you add functions or you modify any given function, please provide comments and descriptions.

Important:
Please make all actions by the server visible by giving some (preferably short) output.

Background Reading


Hints

  • Think before you start implementing.
  • Try to understand the server file and minimize your changes.
  • Use the io:format() command in order to debug.

Examination

  • There are three marks for the project: Pass, Resubmission, and Fail.
  • Your program will be tested for atomicity, consistency and isolation. Please make sure that you test for these as well!
  • The program should be started in the same way it was given to you (without any additional parameters).

Handing in

  • Write your names at the top of server.erl and client.erl
  • Submit an archive (.zip or .tar) containing all your Erlang files, including the ones in the skeleton.
  • Submit using Studentportalen. Under this course, there is a file area called Project. If you work in pairs, only one of you should submit.
  • The deadline is 2016-03-18, 23:59. If you submit after the deadline, I will not be able to correct during this academic year. Therefore, you should try to submit on time!

Updated  2016-01-27 12:21:00 by Cong Quy Trinh.