# This is not the final version, the final version is in dGit

# Milestone Alpha

In the following we descibe each _component_ and its role and the possible concurrency.

### Coordinator
The coordinator manages all of the systems' components, including the database, the load balancer, the estimator, and the servers.

We will use a private field of type `Hashmap<ServerID, Server>` as the datastrucure of choice to manage the servers. This yields an armortised runtime on O(1) for most operations.

With the methods `createServer()`, `scale(int numServers)` and `removeServer(ServerId)`, servers are added or removed from the system at runtime.

The following methods read the systems' state with respect to (active) servers:
- `getActiveServerIds()`
- `getAllServerIds()`
- `pickRandomServer()`
- With `getServerMailbox(ServerId)` and `getEstimatorMailbox()`, we can access the respective mailboxes of servers and the estimator.

Since every component (thread) of the system can access the coordinator concurrently, we need to ensure correct handling by making these methods of the Coordinator `synchronized`.

The _Database_ and _Estimator_ are read-only and will be monitors themselves, such that no further locks are needed for the respective getters.

### Load Balancer

The _Balancer_ is required to handle different requests and has a strong connection to the _Coordinator_. Any management request i.e. _scaling_ or getting a _number of servers_ can just be forwarded to the Coordinator.

In the case of routing to a server, we check if the request has the _Optional_ ServerId and either
- Add the request to the servers' mailbox (which we'll also implement as a monitor)
- Pick a random server and then do the previous step.

The state is saved on the Client-side/Server, such that the LoadBalancer does not have to implement any concurrency controll himself.

### Database

The database has a private field `List<Ticket> unallocated`, which holds all tickets that are currently in the database. By making all methods in the database `synchornized`, we obtain a monitor without missing out on performance. This way, the allocation and deallocaton of tickets in the central database is handled safely, and we do not need further locking of the ticket list.

### Server

Each server will hold a `Semaphore unsoldTickets`, which is initialized to the number of tickets that a server can "check out" of the database upon creation. This way we can check the number of "available permits" left, as well as number of threads waiting to aquire the semaphore, i.e. requests that have been redirected to the server and could not be processed yet. This might be a useful information to find out when to scale the system.

The number of tickets (or: "available permits" of the Semaphore) will not be increased after a successful sale of a ticket, but only when the server takes a new batch with available tickets from the database (with the `release(number)`-method of the semaphore), or when a timeout happens during a reservation. Also, the semaphore does not have an upper bound to its initial value, which means that we are completely flexible when it comes to scaling and "checking out" bigger batches of tickets.

Apart from this, the server of course also needs to have a private field for managing the tickets, e.g.`List<Ticket> unsold` , like the `List<Ticket> unallocated` in the database, which is again only accessed by `synchronized` methods inside the server while processing the request/reservation.

Furthermore, the server needs some form of "terminating" flag/state/variable, where a server is in the process of shutting down, but still processes existing reservations until a successful sale or cancellation.

### Mailbox

The mailbox has to keep track of two message queues (we want to have one for high-priority messages and one for low-priority messages), which will be private fields in the mailbox. Again, by making the methods that perform actions on this message queue `synchronized`, we ensure that only one modifying access at a time can be made to the message queue in terms of sending (adding) and processing (removing) messages from the queue.

### Estimator
The estimator also has the coordinator and a mailbox. Since the mailboxes and read-access to the list of active servers are implemented as monitors, such that the Estimator also does not have to implement any concurrency controll himself.