fluencelabs/redis
1
0
Fork 0
mirror of https://github.com/fluencelabs/redis synced 2025-06-14 09:41:21 +00:00
Code Issues Projects Releases Wiki Activity

Fix MULTI / EXEC rendering in MONITOR output.

Browse Source 
Before of this commit it used to be like this:

MULTI
EXEC
... actual commands of the transaction ...

Because after all that is the natural order of things. Transaction
commands are queued and executed *only after* EXEC is called.

However this makes debugging with MONITOR a mess, so the code was
modified to provide a coherent output.

What happens is that MULTI is rendered in the MONITOR output as far as
possible, instead EXEC is propagated only after the transaction is
executed, or even in the case it fails because of WATCH, so in this case
you'll simply see:

MULTI
EXEC

An empty transaction.
This commit is contained in:
antirez
2012-10-16 17:35:50 +02:00
parent be6cbd3a6e
commit a1b1c1ea3a
3 changed files with 20 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
src/multi.c
View File

@ -96,7 +96,7 @@ void execCommand(redisClient *c) {
c->flags &= ~(REDIS_MULTI|REDIS_DIRTY_CAS);
unwatchAllKeys(c);
addReply(c,shared.nullmultibulk);
return;
goto handle_monitor;
}
/* Replicate a MULTI request now that we are sure the block is executed.
@ -132,6 +132,15 @@ void execCommand(redisClient *c) {
* always send the MULTI command (we can't know beforehand if the
* next operations will contain at least a modification to the DB). */
server.dirty++;
handle_monitor:
/* Send EXEC to clients waiting data from MONITOR. We do it here
* since the natural order of commands execution is actually:
* MUTLI, EXEC, ... commands inside transaction ...
* Instead EXEC is flagged as REDIS_CMD_SKIP_MONITOR in the command
* table, and we do it here with correct ordering. */
if (listLength(server.monitors) && !server.loading)
replicationFeedMonitors(c,server.monitors,c->db->id,c->argv,c->argc);
}
/* ===================== WATCH (CAS alike for MULTI/EXEC) ===================