{"action":"created","issue":{"url":"https://api.github.com/repos/SyncFree/antidote/issues/192","labels_url":"https://api.github.com/repos/SyncFree/antidote/issues/192/labels{/name}","comments_url":"https://api.github.com/repos/SyncFree/antidote/issues/192/comments","events_url":"https://api.github.com/repos/SyncFree/antidote/issues/192/events","html_url":"https://github.com/SyncFree/antidote/pull/192","id":127214896,"number":192,"title":"Fix abort","user":{"login":"tcrain","id":5465025,"avatar_url":"https://avatars.githubusercontent.com/u/5465025?v=3","gravatar_id":"","url":"https://api.github.com/users/tcrain","html_url":"https://github.com/tcrain","followers_url":"https://api.github.com/users/tcrain/followers","following_url":"https://api.github.com/users/tcrain/following{/other_user}","gists_url":"https://api.github.com/users/tcrain/gists{/gist_id}","starred_url":"https://api.github.com/users/tcrain/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tcrain/subscriptions","organizations_url":"https://api.github.com/users/tcrain/orgs","repos_url":"https://api.github.com/users/tcrain/repos","events_url":"https://api.github.com/users/tcrain/events{/privacy}","received_events_url":"https://api.github.com/users/tcrain/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2016-01-18T12:14:13Z","updated_at":"2016-01-18T12:35:00Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/SyncFree/antidote/pulls/192","html_url":"https://github.com/SyncFree/antidote/pull/192","diff_url":"https://github.com/SyncFree/antidote/pull/192.diff","patch_url":"https://github.com/SyncFree/antidote/pull/192.patch"},"body":"This fixes two problems that were making the certification check benchmark crash.\r\n\r\nThe first is when the tx coordinator sends the abort command to the clocksi vnode, the vnode sends back an ack ( https://github.com/SyncFree/antidote/blob/master/src/clocksi_vnode.erl#L366 ), but the coordinator wasn't expecting it, causing it to crash.  Now it waits for the ack to know that the abort was successful.\r\n\r\nThe second was the execution of a static tx made up of updates was expecting a reply of either ok or error ( https://github.com/SyncFree/antidote/blob/master/src/antidote.erl#L169 ), but the tx coordinator could return ok, error, or abort, now it returns either ok or error, but in the information about the error it says it was an abort.\r\n\r\nActually this brings up another issue, some of the functions in the antidote.erl transaction interface return ok, error, or abort, while others just return ok or error (with abort being a possible reason for the error included with the error).  Shouldn't we choose one of these and stick with it, I like the second option personally?  But maybe this would break the protocol buffer as well?"},"comment":{"url":"https://api.github.com/repos/SyncFree/antidote/issues/comments/172517073","html_url":"https://github.com/SyncFree/antidote/pull/192#issuecomment-172517073","issue_url":"https://api.github.com/repos/SyncFree/antidote/issues/192","id":172517073,"user":{"login":"marc-shapiro","id":6663583,"avatar_url":"https://avatars.githubusercontent.com/u/6663583?v=3","gravatar_id":"","url":"https://api.github.com/users/marc-shapiro","html_url":"https://github.com/marc-shapiro","followers_url":"https://api.github.com/users/marc-shapiro/followers","following_url":"https://api.github.com/users/marc-shapiro/following{/other_user}","gists_url":"https://api.github.com/users/marc-shapiro/gists{/gist_id}","starred_url":"https://api.github.com/users/marc-shapiro/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/marc-shapiro/subscriptions","organizations_url":"https://api.github.com/users/marc-shapiro/orgs","repos_url":"https://api.github.com/users/marc-shapiro/repos","events_url":"https://api.github.com/users/marc-shapiro/events{/privacy}","received_events_url":"https://api.github.com/users/marc-shapiro/received_events","type":"User","site_admin":false},"created_at":"2016-01-18T12:35:00Z","updated_at":"2016-01-18T12:35:00Z","body":"\n> Le 18 janv. 2016 à 13:14, tcrain <notifications@github.com> a écrit :\n> \n> This fixes two problems that were making the certification check benchmark crash.\n> \n> The first is when the tx coordinator sends the abort command to the clocksi vnode, the vnode sends back an ack ( https://github.com/SyncFree/antidote/blob/master/src/clocksi_vnode.erl#L366 <https://github.com/SyncFree/antidote/blob/master/src/clocksi_vnode.erl#L366> ), but the coordinator wasn't expecting it, causing it to crash. Now it waits for the ack to know that the abort was successful\n> \nI wonder why: is this logically necessary?  Suppose something goes wrong and the ack is lost, is the abort aborted???\n\nLet me reiterate yet one more time: the fate of a transaction logically depends ONLY on unanimous \"prepare\".  Once all transaction participants have recorded the prepare message in their log, the transaction IS committed, and all entities in the system must reach this same conclusion no matter what happens.  If there is a state where not all participants have recorded prepare, and one knows for sure that this will not happen in the future (e.g. a participant is known to have crashed) then everyone must conclude \"abort\".  The abort message is an optimisation, and the termination should take place even if participants crash or messages get lost.\n\n\t\t\t\t\tMarc\n\n"}}