Coursework CSC8016
Giacomo Bergami
26th of April, 2022
Use Case Scenario
We want to implement a bank system, whether the threads are either clients logging to the servers,
or the bank server containing the information for each account. Each client interacts with the server
through the BankFacade by accessing an openTransaction method, through which the each client can
create multiple accesses to its bank account. This mimicks the possibility of multitasking operations
via mobile phone, ATM, web banking. Each client can only pay or withdraw money, and gets the list
of the total movements after commit-ting the operation. In a realistic scenarios, transactions might
also abort; e.g.:
• The ATM receives the request of money, but the server fails and does not deduct the money
from the on-line account.
• The server fails after deducting the from the on-line account, but no money is given at the ATM
Still, all of the operations done by the thread over the specific bank account will be confirmed and will
become effective only when the transaction is going to be committed. After a commit or an abort,
no further operation through that transaction is allowed, thus requiring the user to open another
transaction within the same thread. More details on the operations’ requirements are given in the
final marking scheme.
As in any industrial setting where teams split up the duties, you are assigned an API that you need
to implement. Such an API is provided both on Canvas and at https://github.com/jackbergus/
NCL_CSC8016. This will then require to extend the BankFacade for implementing the definition of
novel transactions, and the implementation of TransactionCommands for performing the client-server
communication. The student is free to choose whichever is the best way to make these two entities
communicate. E.g., the bank could be either modelled as a finer-grained monitor, but inside this
monitor at least one thread per logged user should be running; also, such a bank could be also
implemented as a consumer threads handling all of the clients’ messages.
Assumptions
• In a realistic example, communications happen between processes via UDP messages. In this
module, we don’t require that. We can freely assume that each client (ATM, OnLine Banking) is
mimicked by one single thread. We assume they directly exploit such an interface (no FrontEnd
is required!)
• If the bank is implemented as a server, such a thread might receive the “client messages” through
shared variables.
1
• The server should also keep track of the transactions that are performed for handling commit/abort
correctly. You are not required to tolerate the server crash (this is more of a back-up
task rather than a concurrent programming one), but you must tolerate the client ones (that is
more related to concurrent programs’ management)!
• We assume that the BankFacade class is initialized with the users having an account in their
bank as well as the balance associated to that (constructor with HashMap