Si necesita revertir la transacción, le recomiendo usar algo que no sea Redis. Las transacciones de Redis no son las mismas que para otros almacenes de datos. Incluso Multi/Exec no funciona para lo que desea, primero porque no hay reversión. Si desea revertir, tendrá que desplegar ambas listas para poder restaurar, y esperar que entre nuestra condición de error y la "reversión" ningún otro cliente haya modificado ninguna de las listas. Hacer esto de forma sensata y fiable no es baladí, ni sencillo. Probablemente tampoco sería una buena pregunta para SO, ya que sería muy amplia y no específica de Redis.
Ahora, en cuanto a por qué EXEC no hace lo que uno podría pensar. En su escenario propuesto, MULTI/EXEC solo maneja los casos de:
- Configuró RELOJES para asegurarse de que no ocurrieron otros cambios
- Su cliente muere antes de emitir EXEC
- Redis no tiene memoria
Es completamente posible obtener errores como resultado de emitir el comando EXEC. Cuando emite EXEC, Redis ejecutará todas comandos en la cola y devolver una lista de errores. No proporcionará el caso de que add-to-list-1 funcione y add-to-list-2 falle. Todavía tendrías tus dos listas desincronizadas. Cuando emita, diga un LPUSH después de emitir MULTI, siempre obtendrá un OK a menos que usted:
- a) agregó previamente un reloj y algo en esa lista cambió o
- b) Redis devuelve una condición OOM en respuesta a un comando push en cola
DISCARD no funciona como algunos podrían pensar. DESCARTAR se usa en lugar de EXEC, no como un mecanismo de reversión. Una vez que emite EXEC, su transacción se completa. Redis no tiene ningún mecanismo de reversión; de eso no se trata la transacción de Redis.
La clave para comprender lo que Redis llama transacciones es darse cuenta de que son esencialmente una cola de comandos en el nivel de conexión del cliente. No son una máquina de estado de base de datos.
