Reference Guide

- The distributed map is already in memory and serves this purpose. If your application
needs this data to be available if and when the coordination service is down then a local
cache could be appropriate as well as reading from persistence any previously saved
records to startup the cache in those scenarios.
3. Minimize tying map entry listeners to persistence.
- Consider how important it is for your data to be persisted before automatically tying a
distributed map entry listener for the purpose of writing to the database.
Distributed Lock
Protecting the access to shared resources becomes increasingly important in a distributed
environment. A lock is a synchronization primitive that ensures only a single thread is able to
access a critical section. Distributed Locks offered by the Coordination Service provides an
implementation of locks for distributed environments where threads can run either in the same JVM
or in different JVMs.
Applications needs to define a namespace that is used as the lock identity to make sure
application instances running on different JVMs acquire the right lock. Applications on different
controller nodes should agree upon the namespace and acquire the necessary lock on it before
accessing the shared resource.
A distributed lock extends the functionality of java.util.concurrent.locks.Lock and thus it can be
used as a regular Java lock with the following differences:
Locks are automatically released when a member (node) has acquired a lock and this member
goes down. This prevents threads that are waiting for a lock from waiting indefinitely. This is
needed for failover to work in a distributed system. The downside however is that if a member
goes down that acquired the lock and started making changes, other members could start to see
partial changes.
Distributed Lock Example:
Namespace namespace = Namespace.forReplicatedProcess(getClass());
Lock lock = coordinationService.getLock(namespace);
lock.lock();
try {
// access the resources protected by this lock
} finally {
lock.unlock();
}
Data Versioning with Google Protocol Buffers (GPB)
For the long term maintainability, interoperability, and extensibility of application data it is
recommended that applications version the data they write using the different coordination
services. Google Protocol Buffers (GPB) is the recommended versioning mechanism for these
services that is supported by the SDK. The section below introduces GPBs and their use for
message versioning with application’s model objects. It is recommended the reader reference the
official GPB documentation to understand the complete syntax and all the features available for
the programming language of choice for your application. [50]
75