Details
-
Sub-task
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
Description
To ensure that volume operations are idempotent, we should first compare the transactionID with the objectID and updateID to make sure that the transaction is not a replay. If the transactionID <= updateID, then it implies that the transaction is a replay and hence it should be skipped.
After this patch, the replay behavior for volume operations will be as follows:
Lets say we have the following transactions:
Tx 10 - CreateVolume (Vol1, objectID = 10, updateID = 10, owner = o1, quota = 100)
Tx 12 - SetOwner (Vol1, objectID = 10, updateID = 12, owner = o2, quota = 100)
Tx 20 - SetQuota (Vol1, objectID = 10, updateID = 20, owner = o2, quota = 200)
Tx 28 - DeleteVolume (Vol1)
Tx 40 - CreateVolume (Vol1, objectID = 40, updateID = 40, owner = o1, quota = 100)
Tx 50 - SetOwner (Vol1, objectID = 40, updateID = 50, owner = o3, quota = 100)
On replaying these transactions:
Replay Tx 10 - Vol1 already exists => Tx will throw VOLUME_ALREADY_EXISTS when trying to createVolume
Replay Tx 12 - UpdateID (50) is more than equal to TxID (12) => Tx will not update DB (return ReplayResponse in validateAndUpdateCache)
Replay Tx 20 - UpdateID (50) is more than equal to TxID (20) => Tx will not update DB (return ReplayResponse in validateAndUpdateCache)
Replay Tx 28 - UpdateID (50) is more than equal to TxID (28) => Tx will not update DB (return ReplayResponse in validateAndUpdateCache)
Replay Tx 40 - Vol1 already exists => Tx will throw VOLUME_ALREADY_EXISTS when trying to createVolume
Replay Tx 50 - UpdateID (50) is more than equal to TxID (28) => Tx will not update DB (return ReplayResponse in validateAndUpdateCache)
So none of the transactions will effect any change in the DB.
Attachments
Issue Links
- links to