Implications
Applications built on top of optimistic replicated databases need to be careful about ensuring that the delayed updates observed do not impair the correctness of the application.
As a simple example, if an application contains a way of viewing some part of the database state, and a way of editing it, then users may edit that state but then not see it changing in the viewer. Alarmed that their edit "didn't work", they may try it again, potentially more than once. If the updates are not idempotent (e.g., they increment a value), this can lead to disaster. Even if they are idempotent, the spurious updates place a burden on the database system - and the situation in which replication delays become particularly noticeable is when the database system is at a high level of load anyway; this can become a vicious circle.
Testing of applications is often done on a testing environment, smaller in size (perhaps only a single server) and less loaded than the "live" environment. The replication behaviour of such an installation may differ from a live environment in ways that mean that replication lag is unlikely to be observed in testing - masking replication-sensitive bugs. Application developers must be very careful about the assumptions they make about the effect of a database update, and must be sure to simulate lag in their testing environments.
Optimistically replicated databases have to be very careful about offering features such as validity constraints on data. If any given update may or may not be accepted based on the current state of the record, then two updates (A and B) may be individually legal against the starting state of the system, but one or more of the updates may not be legal against the state of the system after the other update (e.g., A and B are both legal, but AB or BA are illegal). If A and B are both initiated at roughly the same time within the database, then A may be successfully applied on some nodes and B on others, but as soon as A and B "meet" and one is attempted on a node which has already applied the other, a conflict will be found. The system must, in this case, decide which update finally "wins", and arrange for any nodes that have already applied the losing update to revert it. However, some nodes may temporarily expose the state with the reverted update, and there may be no way to inform the user who initiated the update of its failure, without requiring them to wait (potentially forever) for confirmation of acceptance at every node.
Read more about this topic: Optimistic Replication
Famous quotes containing the word implications:
“The power to guess the unseen from the seen, to trace the implications of things, to judge the whole piece by the pattern, the condition of feeling life in general so completely that you are well on your way to knowing any particular corner of it—this cluster of gifts may almost be said to constitute experience.”
—Henry James (1843–1916)
“Philosophical questions are not by their nature insoluble. They are, indeed, radically different from scientific questions, because they concern the implications and other interrelations of ideas, not the order of physical events; their answers are interpretations instead of factual reports, and their function is to increase not our knowledge of nature, but our understanding of what we know.”
—Susanne K. Langer (1895–1985)
“When it had long since outgrown his purely medical implications and become a world movement which penetrated into every field of science and every domain of the intellect: literature, the history of art, religion and prehistory; mythology, folklore, pedagogy, and what not.”
—Thomas Mann (1875–1955)