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