Choose and implement a strategy for concurrency control of the transactions.
In your choice of the 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).
Example of strategies: two-phase locking, 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.
- 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.
- Think before you start implementing.
- Try to understand the server file and minimize your changes.
- Use the io:format() command in order to debug.
- You will be asked to submit an archive (.zip or .tar) containing all your Erlang files.
- The program should be started in the same way it was given to you (without any additional parameters).
- You may be asked to run your system and provide several scenarios in order to show how your program meets the requirements listed above.
You may have guessed by now that communication between processes is handled by Erlang nodes. So far, we have assumed that the communication is reliable (and actually it is) in the sense that:
- Every sent message will be eventually received.
- The order by which messages are sent is preserved at the receive operations.
Examine the last two functions in the client module:
- The function loose(LossParameter) takes a value and then decides with a certain probability, depending on the parameter, whether or not to loose the message. So far the parameter was fixed at 0 and no message loss could occur.
On top of your changes related to concurrency control, you are supposed to modify certain parts of the client and server modules in order to handle the case where message losses could occur. In order to do that, you are allowed to modify the send() function on the client side (and you are free to change the server module as suited). You are also allowed to add other functions and call them from send() in the client module. Observer that for simplicity, we assume that messages can be lost only in one direction: Client to Server.
- Client: Think about how to modify the syntax of action messages by adding tags (numbers from 1 to the size of the transaction).
- Server: Think about how to check these tags on the server side in order to continue or ask for a re-send.
Your program will be compiled and tested for different values of loss probability. It is expected to work properly regardless of that (for all values < 1).