You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thing modifications in Ditto are subject to the classic "lost updates" problem known from relational databases.
With support for a per-feature _revision field being in the loop (#778) it would be possible to detect concurrent modifications.
a twin exists in Ditto having feature XYZ set to 1 (revision 0)
client A sends feature update (XYZ=2, rev. 0)
Ditto processes client As request
client B sends feature update (XYZ=3, rev. 0)
Ditto updates the twins feature to XYZ=2, rev. 1 and sends an event to client B (client A doesn't receive one since it initiated the update)
client B receives the event and updates its internal state to XYZ=2, rev. 1
Ditto processes client Bs request
In this last step with the current implementation Ditto would just update the twins feature to XYZ=3, rev. 2 and send the update event to client A (but not B), leaving client B with a wrong state (its update is lost).
In a future implementation Ditto should compare the revision sent along with the request of client B (rev. 0) with the twins feature revision at that time (rev. 1 after As update) and raise an error that the feature has been modified in the meanwhile.
Probably its reasonable to make this behavior configurable (system wide or per client / request)
The text was updated successfully, but these errors were encountered:
What is missing is providing that as well on a feature or even on a deeper level. There currently only the hash can be used for using in the conditional request and this hash is the Java hash code which is most of the times difficult to calculate.
So once we would have the revision number in each Json leaf as metadata, the conditional request could be done everywhere.
Thing modifications in Ditto are subject to the classic "lost updates" problem known from relational databases.
With support for a per-feature _revision field being in the loop (#778) it would be possible to detect concurrent modifications.
In this last step with the current implementation Ditto would just update the twins feature to XYZ=3, rev. 2 and send the update event to client A (but not B), leaving client B with a wrong state (its update is lost).
In a future implementation Ditto should compare the revision sent along with the request of client B (rev. 0) with the twins feature revision at that time (rev. 1 after As update) and raise an error that the feature has been modified in the meanwhile.
Probably its reasonable to make this behavior configurable (system wide or per client / request)
The text was updated successfully, but these errors were encountered: