PEAA.5 – Concurrency

Concurrency occurs when different processes or applications need the same resource to continue to work. To understand when this happens and how to deal with these issues, we need to talk about execution contexts, racing conditions, inconsistent reads, deadlocks and transactions.

Execution contexts

Processing always occurs in some kind of context, usually more than one. An enterprise application will usually have Requests and Sessions both as a server to clients ans as a client to other applications like a DB server or a 3rd party application API.

  • Request
    A single short term call from the outside world to the application, which may result in it returning a response.
  • Session
    A long term interaction between client and server, usually consisting of a series of requests.
  • Process
    A heavyweight context that provides isolation to the data it works on.
  • Thread
    A lightweight context that is set up so that several threads are ran in a single process. They support multiple requests in a single process, helping to make good usage of resources. However, because they run in a single process, they share memory, which leads to concurrency problems.
  • Transaction
    A transaction groups together several Requests that the application wants to treat as a single Request. We can have system transactions (ie. connecting to a DB) or business transactions (ie. a user interacting with the application)

Racing conditions

Concurrency problems occur when more than one active agent modifies the same data at the same time. These are called racing conditions.

  • Isolation
    By only allowing one active agent to modify a specific portion of data at any given time, we avoid concurrency issues. This can be accomplished by using a lock to inform the application that a specific set of data only be opened for reading.
  • Immutability
    By identifying and flagging data sets that can not be changed we reduce the scope where concurrency issues might occur.
  • Pessimistic concurrency control
    When 2 users want to edit a file at the same time, only the one who opens the file first can edit the file. The second user can only edit the file when the first user is finished with it. This prevents concurrency problems.
  • Optimistic concurrency control
    In the same situation as above, both the users would be able to edit the file, but only the first one to finish would be able to save it immediately. The second user would have to merge his changes with the new version of the file before he can save his work.

Inconsistent reads

An inconsistent read happens when  a user reads some data and that data is changed by another user while he is still using the data. The data he read and is still using, is then inconsistent.

  • Pessimistic lock solution
    Using a pessimistic lock we need to acquire a shared lock for reading and an exclusive lock for writing. However, the rules to acquire a lock are:

    • Any number of shared locks can be acquired at any given time, as long as there is no exclusive lock acquired.
    • An exclusive lock can be acquired at any given time, as long as no other lock (shared or exclusive) has been acquired.
  • Optimistic lock solution
    With an optimistic lock, every piece of data has a version tag on it. When making an update, the system checks for differences in data versions. If a difference is detected, a conflict is raised.

Deadlocks

A deadlock happens when two processes have locks on different resources and suddenly they both require each others locked resources in order to finish their job and releasing their lock. This means they would both be waiting for each others locks to be released.

  • Victim through detection
    When we detect a deadlock, we can choose one of the processes to be forces tu terminate so the other can continue. This means the victim process would stop and lose his state.
  • Victim through timed process
    Detecting a deadlock is very difficult. An easier solution is to give a time linit to a process, after which the process will be killed. This means the victim process would stop and lose his state even though maybe there was no deadlock.
  • Preventive lock
    To prevent deadlocks we can force processes to acquire all necessary locks in the beginning and prevent them acquiring more.
  • Automatic victim
    We can also make it so that when a process tries to acquire a lock on an already locked resource, it automatically becomes a victim.
  • Mixed strategies
    We can adopt an extreme solution, by mixing different strategies. For example using preventive locks and also timed processes.

Transactions

A transaction is what guarantees that a sequence of actions are all successfully and fully executed, or none is.

ACID

  • Atomicity
    All actions in a transaction are guaranteed to complete successfully or none is executed
  • Consistency
    A system resources must be in a consistent, non corrupt state at the start and end of a transaction.
  • Isolation
    The result of a transaction is only visible when the whole transaction is finished.
  • Durability
    The result of a transaction must be permanent.

Transaction types

  • Long transaction
    Spans several requests
  • Request transaction
    Always starts in the beginning of a request and finishes in the end of the request.
  • Late transaction
    As a request transaction, but it is open as late as possible, allowing the reads to be made outside of the transaction.
  • System transaction
    A transaction that operates at the infrastructure level, usually when communicating to the DB.
  • Business transaction
    A transaction that operates at a use case level, ie. encompasses several user screens from the beginning of the use case flow until its end.
This post is part of a set of posts with my personal notes about all the chapters in the book “Patterns of Enterprise Application Architecture” by Martin Fowler. I will do this as I read through the book, and take notes on the concepts I personally find more relevant.
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s