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

• The store handles 4 global variable a, b, c and d which can be regarded as accounts for example.
• 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 will be visible. The clients are supposed to establish connection and then send transaction requests to the server which may respond by a committed or aborted message.

The client process provides a graphical interface via 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 provide a set of actions which will be collected by the handler. In case 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

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.

Before starting the system, you are strongly recommended to get familiar with the following concepts.

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

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

• Now open different terminals and enter the directory where you compiled the skeleton (in each one of them).

• 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 distant 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 compiled the skeleton and similarly start an Erlang node and a client as it is 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).

• 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.