Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor(epaxos.go) add comments for updateAttr and conflicts map #4

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

refactor(epaxos.go) add comments for updateAttr and conflicts map #4

wants to merge 2 commits into from

Conversation

xiang90
Copy link

@xiang90 xiang90 commented Dec 13, 2013

@imoraru
I just begin to go through the codebase. Add some comments.
One question:
Is there any documentation about the checkpoint stuff? Is that only for clearing the dep map?
Can we just update the map after executing a command, like

id, ok := dep[c.Key]
if ok && id == c.Id {
    delete(dep, c.Key)
}

@imoraru
Copy link
Member

imoraru commented Dec 13, 2013

RIght now, the checkpointing thing is just for clearing the map, so that it doesn't get too big.
It's not safe to clear the map after executing on the local replica, because some remote replica may not have executed that command --- so it is necessary to be able to give that replica correct dependencies for subsequent commands. If, on the other hand, everyone says they have executed, it is safe to delete (but in Paxos you cannot assume that all replicas will respond, hence the checkpointing as a way to delete the map without everyone responding).

In general, I would say it's useful to look at the code, if you think it will help you understand the protocol better, but I would have started with the communication part first.

@xiang90
Copy link
Author

xiang90 commented Dec 13, 2013

@imoraru Sure. I will start with the communication part.

@xiang90
Copy link
Author

xiang90 commented Dec 13, 2013

@imoraru
Yea. You are right. Just to clarify the problem (since some of my friends will also read this).
I think there are three cases for the clearance of the deps map after execution:

  1. the remote replica has also executed the command. There should not be any problem in this case.
  2. the remote replica has received the command, but has not executed it yet(maybe committed or uncommitted).
    In this case, the remote replica will add the command into deps and send it back if there is an interference with that command. The command leader can make decision based on the situation.
  3. the remote replica has not received the command.
    Both the remote replica and the command leader(who has executed the command) will not add the command into deps. But the command should be in the deps of the remote replica.
    In this case, there will be a problem that cannot be solved without other information (such as last received instance.id etc.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants