ERR WATCH inside MULTI is not allowed

Skip to first unread message

surya megham

Aug 22, 2021, 5:01:50 PMAug 22
to Redis DB
Hi Guys,

I'm using redis connection pool, where multiple concurrent requests will run the Watch-Multi-Exec-Unwatch combination on each request of dedicated connection, of-course after request served the connection will go back to pool.

Intermittently, the requests are failing with "ERR WATCH inside MULTI is not allowed".  In my code i'm not using the Watch inside the Multi at all.

Does any one have any idea ? what is going on ?

Is there a possibility that the old requests are still Queued up at Redis and new request is using the same connection and submitted to Redis and both commands are colliding each other ??

Greg Andrews

Aug 23, 2021, 6:10:54 AMAug 23
to Redis DB
It's not likely the Redis server's input buffering is mixing up concurrent requests through the same TCP connection.  It's more likely your client's connection pool layer is doing this.  A connection pool manager for Redis should know to collect the full MULTI/command/command/EXEC sequence from the thread and transmit it to Redis together, but maybe yours isn't doing that. Are your threads delivering the full sequence of MULTI/command/command/EXEC to the connection pool manager in a single write, to make it harder for the pool manager to interleave commands from other threads in the middle of the sequence?

surya megham

Aug 23, 2021, 8:35:46 AMAug 23
to Redis DB
I think you are making sense, as there can be a situation where the code can throw an exception between Multi and Exec can cause the Transaction to open forever and the connection goes back to pool. The next request might reuse the same connection where Redis has a track that this connection has opened a transaction a little while ago and not closed. hence, the Watch command of the next request will fail with ERR WATCH inside MULTI is not allowed.

My theory is logical here? I can inspect my code and probably will execute the DISCARD command in the finally block, which will ensure no more open transactions in those edge cases.

Thank you for discussing this, it made me think in a different way to deal with this problem.

Reply all
Reply to author
0 new messages