Skip to content

Wrap also propagate as multi#6615

Merged
antirez merged 4 commits intoredis:unstablefrom
soloestoy:wrap-also-propagate-as-multi
Dec 19, 2019
Merged

Wrap also propagate as multi#6615
antirez merged 4 commits intoredis:unstablefrom
soloestoy:wrap-also-propagate-as-multi

Conversation

@soloestoy
Copy link
Contributor

@soloestoy soloestoy commented Nov 22, 2019

Hi @antirez @madolson , now I open this PR to discuss the codes I mentioned in #6152 , except the original problem, here are other three changes:

  1. propagate EXEC directly in lua script

    I think we don't need to use also propagate in lua, cause MULTI is already propagated.

  2. flag module client as CLIENT_MULTI if needed

    In case of nested MULTI/EXEC, lua script has the same problem, see details in scripting: flag lua_client as CLIENT_MULTI after redis.replicate_command() immediately #5780

  3. propagte BRPOPLPUSH as RPOPLPUSH when unblock

    After the expire problem is fixed, I think it's OK to do that now

BTW, if this PR is OK, before merge it we should merge #5780 at first to avoid nested MULIT/EXEC when SPOP with count is called in lua script.

Random command like SPOP with count is replicated as
some SREM operations, and store them in also_propagate
array to propagate after the call, but this would break
atomicity.

To keep the command's atomicity, wrap also_propagate
array with MULTI/EXEC.
@antirez
Copy link
Contributor

antirez commented Nov 25, 2019

Thanks @soloestoy, quick question before reviewing it: during the creation of this PR, did you also check that the modules propagation APIs will play well with the change? Since now the modules APIs used alsoPropagate() and used to send the EXEC after the context was destroyed.

@soloestoy
Copy link
Contributor Author

Yes @antirez I notice that, so I check the module context if multi emitted or the client is already in a transaction then just flag module client with CLIENT_MULTI to avoid nested MULTI/EXEC in commit 2c97053

@antirez antirez merged commit d3a9dff into redis:unstable Dec 19, 2019
@antirez
Copy link
Contributor

antirez commented Dec 19, 2019

Thanks @soloestoy, PR merged.

@antirez
Copy link
Contributor

antirez commented Dec 19, 2019

To be honest I don't remember if the reason why BRPOPLPUSH was propagated as two commands was because of the expire. Probably yes? Commit is too old, and there was no clear description about why it was propagated in that way.

JackieXie168 pushed a commit to JackieXie168/redis that referenced this pull request Dec 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants