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
Idem is capable of detecting backwards clock drift and handling these situations as appropriate. However, this feature is currently application-scoped. Hence, if the service restarts, all knowledge that enables us to track backwards clock drifts is lost.
Idem needs to work reliable in between application restarts as well. For this, we have to track the last point in time in milliseconds since the epoch at which Idem has generated the last ID. This knowledge needs to be persisted. As soon as the application restarts, Idem needs to check for a backwards clock drift and is required to delay any ID generation until the clock caught up.
During normal operation times, this is no big deal, since backwards clock drift is in the range of a couple of seconds. This feature would however delay the generation of new IDs when the clock changes significantly due to adjusting for daylight savings time (or goes back to normal time). It is unclear as of now how we should handle this.
Persisting the last known point in time at which Idem generated an ID should be an optional feature.
The text was updated successfully, but these errors were encountered:
Idem is capable of detecting backwards clock drift and handling these situations as appropriate. However, this feature is currently application-scoped. Hence, if the service restarts, all knowledge that enables us to track backwards clock drifts is lost.
Idem needs to work reliable in between application restarts as well. For this, we have to track the last point in time in milliseconds since the epoch at which Idem has generated the last ID. This knowledge needs to be persisted. As soon as the application restarts, Idem needs to check for a backwards clock drift and is required to delay any ID generation until the clock caught up.
During normal operation times, this is no big deal, since backwards clock drift is in the range of a couple of seconds. This feature would however delay the generation of new IDs when the clock changes significantly due to adjusting for daylight savings time (or goes back to normal time). It is unclear as of now how we should handle this.
Persisting the last known point in time at which Idem generated an ID should be an optional feature.
The text was updated successfully, but these errors were encountered: