Databases Reference
In-Depth Information
Their focus is on messaging rather than memory locks. Once a transform is complete,
the only artifact is the output document. All intermediate values are easily removed
and the lack of side effects makes testing functions an atomic process.
Functional programming languages also may have type checking for input and
output parameters, and validation functions that execute on incoming items. This
makes it easier to do compile-time checking and produces accurate runtime checks
that can quickly help developers to isolate problems.
Yet all these safeguards won't replace a robust and consistent unit-testing process.
To avoid sending corrupt, inconsistent, and missing data to your functions, a compre-
hensive and complete testing plan should be part of all projects.
10.4.7
Concurrency in functional programming
Functional programming systems are popular when multiple processes need to reli-
ably share information either locally or over networks. In the imperative world, shar-
ing information between processes involves multiple processes reading and writing
shared memory and setting other memory locations called
locks
to determine who has
exclusive rights to modify memory. The complexities about who can read and write
shared memory values are referred to as
concurrency problems
. Let's take a look at some
of the problems that can occur when you try to share memory:
Programs may fail to lock a resource properly before they use it.
Programs may lock a resource and neglect to unlock it, preventing other
threads from using a resource.
Programs may lock a resource for a long time and prevent others from using it
for extended periods.
Deadlocks occur where two or more threads are blocked forever, waiting for
each other to be unlocked.
These problems aren't new, nor are they exclusive to traditional systems. Traditional
as well as NoSQL systems have challenges locking resources on distributed systems
that run over unreliable networks. Our next case study looks at an alternative
approach to managing concurrency in distributed systems.
10.5
Case study: building NoSQL systems with Erlang
Erlang is a functional programming language optimized for highly available distrib-
uted systems. As we mentioned before, Erlang has been used to build several popular
NoSQL systems including CouchDB, Couchbase, Riak, and Amazon's SimpleDB. But
Erlang is used for writing more than distributed databases that need high availability.
The popular distributed messaging system RabbitMQ is also written in Erlang. It's no
coincidence that these systems have excellent reputations for high availability and
scalability. In this case study, we'll look at why Erlang has been so popular and how
these NoSQL systems have benefited from Erlang's focus on concurrency and mes-
sage-passing architecture.
