Configuring Bootstrap from a Cache Peer
When a peer comes up, it will be incoherent with other caches. When the bootstrap completes it will be partially coherent. Bootstrap gets the list of keys from a random peer, and then loads those in batches from random peers. If bootstrap fails then the Cache will not start. However if a cache replication operation occurs which is then overwritten by bootstrap there is a chance that the cache could be inconsistent.
Here are some scenarios:
Delete overwritten by bootstrap put:
1. Cache A keys with values: 1, 2, 3, 4, 5
2. Cache B starts bootstrap
3. Cache A removes key 2
4. Cache B removes key 2 and then bootstrap puts it back
Put overwritten by bootstrap put:
1. Cache A keys with values: 1, 2, 3, 4, 5
2. Cache B starts bootstrap
3. Cache A updates the value of key 2
4. Cache B updates the value of key 2 and then bootstrap overwrites it with the old value
The solution is for bootstrap to get a list of keys and write them all before committing transactions.
This could cause synchronous transaction replicates to back up. To solve this problem, commits will be accepted, but not written to the cache until after bootstrap. Coherency is maintained because the cache is not available until bootstrap has completed and the transactions have been completed.
|
Feedback