We have described the synchronisation mechanisms between end systems
when they communicate. We now discuss synchronisation between
instances of communication.
In a distributed system, many concurrent applications may attempt to access the
same object simultaneously. The classic example is that of access to a bank
account database and is shown in #fnconsist#607>.
Two clerks start to update the same bank account as they clear two separate
cheques:
#figure608#
Figure: Distributed Access and Consistency
Consider the different order in which these operations can occur in #fnconsist#611>:
If B.1 happens between A.1 and A.3, or A.1 happens between B.1 and B.3, account
P would be short 23 or 42 dollars respectively. Any other ordering has the
desired effect.
What is required is some synchronization mechanism. It is worth noting for now
that if A and B had been accessing different accounts, or A and/or B only
<#612#> read<#612#>
the account, then no synchronization would be necessary.
The solution is to provide a locking mechanism. Each application must acquire a
lock before attempting its set of operations. Setting locks must be
indivisible with respect to the normal operations.
Locks should apply to groups of operation at an appropriate
level of granularity.
There is a tradeoff of concurrency versus blocking,
which will need adjusting based on
the number of commonly linked operations by a single client
versus the number of clients concurrently carrying out operations.
A problem then arises as to when to release the locks: Next we see how
transactions help structure these sets of operations.