diff --git a/README.md b/README.md
index 8e0f90235..394f0b899 100644
--- a/README.md
+++ b/README.md
@@ -64,12 +64,11 @@ queries*.
queries are not atomic.
- Consistency - doesn't make sense for key-value stores
- Isolation - yes (for both single- and multi-key queries).
- - Durability - no, at most, Chronicle Map could be persisted to disk. **Durability with Chronicle
- Map is provided by another level of architecture,** for example all requests are sent to several
- nodes - master and hot standby. Clustering/distributed architecture is out of the scope of the
- Chronicle Map project, there are projects *on top* of Chronicle Map which address these questions,
- e. g. [Chronicle Enterprise](http://chronicle.software/products/chronicle-enterprise/).
-
+ - Durability - no, Chronicle Map can be persisted to disk but with no guarantee as to to how frequently this
+ happens - this is under the control of the OS. All data is guaranteed to be written to disk when the Map is closed.
+ **Clustering and replication for Chronicle
+ Map is provided by [Chronicle Map Enterprise](http://chronicle.software/products/chronicle-map/).**
+
**Project status: ready for production.**
**What is the Chronicle Map's data structure?** In one sentence and simplified, a Chronicle Map
@@ -108,17 +107,18 @@ Chronicle Map doesn't support
| Remote calls |
-
- Closed-source, on-demand |
+
+ Closed-source |
| Eventually-consistent replication (100% redundancy) |
- | Partially-redundant replication |
+ Synchronous replication |
- | Synchronous replication |
+ Partially-redundant replication |
+ On-demand |
| Entry expiration timeouts |
@@ -128,7 +128,7 @@ Chronicle Map doesn't support
### License
Chronicle Map is distributed under LGPLv3. If you want to obtain this software under more permissive
-license, please contact the copyright holders.
+license, please contact sales@chronicle.software.
### Peer projects
- [Chronicle Engine](https://github.com/OpenHFT/Chronicle-Engine) - reactive processing framework
@@ -1672,7 +1672,7 @@ Combined, interception SPI interfaces and `ChronicleMap.queryContext()` API are
- Log some specific operations on `ChronicleMap` (e. g. log only acquireUsing() calls, which has
created a new entry)
- Forbid performing operations of some kind on the `ChronicleMap` instance
- - Backup all changes to `ChronicleMap` to some durable storage, e. g. SQL database
+ - Backup all changes to `ChronicleMap` to some alternative storage, e. g. SQL database
- Perform multi-Chronicle Map operations correctly in concurrent environment, by acquiring locks on
all ChronicleMaps before updating them.
- Perform multi-key operations on a single `ChronicleMap` correctly in concurrent environment, by
diff --git a/src/main/java/net/openhft/chronicle/map/ReplicatedChronicleMap.java b/src/main/java/net/openhft/chronicle/map/ReplicatedChronicleMap.java
index fb4f14fca..3aff5ec2f 100644
--- a/src/main/java/net/openhft/chronicle/map/ReplicatedChronicleMap.java
+++ b/src/main/java/net/openhft/chronicle/map/ReplicatedChronicleMap.java
@@ -82,6 +82,9 @@ import static net.openhft.chronicle.hash.replication.TimeProvider.currentTime;
* made to one node should be identical to the decision made to the other. We resolve this simple
* dilemma by using a node identifier, each node will have a unique identifier, the update from the
* node with the smallest identifier wins.
+ * This a one of the basic building blocks needed to implement a fully-functioning Chronicle Map
+ * cluster, such as that provided in
+ * Chronicle Map Enterprise.
*
* @param the entries key type
* @param the entries value type