[CONTROLLER-1490] Allow Shard to persist commits asynchronously Created: 24/Feb/16 Updated: 25/Jul/23 Resolved: 24/Dec/16 |
|
| Status: | Resolved |
| Project: | controller |
| Component/s: | clustering |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Robert Varga | Assignee: | Tom Pantelis |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Issue Links: |
|
||||||||
| External issue ID: | 5419 | ||||||||
| Description |
|
DataTree allows preparing a chain of commits which are applied in order. This capability is useful for hiding persistence and replication latency in clustered scenarios. This amounts to handling multiple transaction commits, and sending state changes into persistence asynchronously. Explore what options we have in interacting with persistence and what effects this has no message ordering. We definitely do not want to persist all events asynchronously, as some of these are mean state transitions which must happen before we accept any new messages. |
| Comments |
| Comment by Tom Pantelis [ 17/Nov/16 ] |
|
Patches: https://git.opendaylight.org/gerrit/#/c/48440/ |