rollback question: which redis command can fail?

[Jak Sprats]

in Salvatore's talk in San Fran, he said, only one transaction in all
of Redis' commands can fail, therefore the idea of rollbacks is not
really needed.

which transaction is this? I didnt get the name

[Pieter Noordhuis]

I'm not sure what you mean. The basic idea is this: MULTI/EXEC is often called a transaction, because people find it easier to understand instead of calling it a "atomically executed block of commands". However, Redis doesn't support rollbacks. Every command in the M/E block is executed serially, so also errors will just be returned. The only guarantee that M/E gives is atomicity of the executed commands (all the ACID properties hold, by the way).

I hope this clarifies things a bit.

Cheers,

Pieter

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To post to this group, send email to redi...@googlegroups.com.
To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.

[Konstantin Merenkov]

On Mon, Jun 28, 2010 at 7:57 AM, Pieter Noordhuis <pcnoo...@gmail.com> wrote:
> I'm not sure what you mean. The basic idea is this: MULTI/EXEC is often
> called a transaction, because people find it easier to understand instead of
> calling it a "atomically executed block of commands".

No, it is called a transaction because it is said so in redis
documentation. And it tricked helluvalot of people. I lived through
some hot debates about it.

Though it is not a big deal because usually commands fail to apply due
to operating on a wrong type of key. Like, sadd on a hash will result
in error.
But it is about fixing bugs in your own software :-)

--
Best Regards,
Konstantin Merenkov

[Jak Sprats]

thanks Pieter and Konstantin, good news for me :)

In many years of programming, I have only used transactions for
transferring money, for all other use cases I have engineered around
transactions because they introduce complexity/locks/etc...

Many "rollbacks" can/should be implemented in client side logic where
needed.

here is an example of a TRANSACTION transfering $100 between accounts
amount = 100
WATCH account:1:amount
WATCH account:2:amount
MULTI
val = GET account:1:amount
val = val + amount
secondval = GET account:2:amount
secondval = secondval - amount
SET account:1:amount $val
SET account:2:amount $secondval
EXEC
UNWATCH account:1:amount
UNWATCH account:2:amount

Will this work? My understanding of MULTI/EXEC is if either of the two
watched keys (account:1:amount OR account2:amount) has been modified
since the WATCH, then the entire MULTI/EXEC command-list will not even
get run ... is this correct? So this "transaction" will either succeed
or fail, but not be done halfways.

On Jun 27, 11:27 pm, Konstantin Merenkov <kmeren...@gmail.com> wrote:

> On Mon, Jun 28, 2010 at 7:57 AM, Pieter Noordhuis <pcnoordh...@gmail.com> wrote:
> > I'm not sure what you mean. The basic idea is this: MULTI/EXEC is often
> > called a transaction, because people find it easier to understand instead of
> > calling it a "atomically executed block of commands".
>
> No, it is called a transaction because it is said so in redis
> documentation. And it tricked helluvalot of people. I lived through
> some hot debates about it.
>
> Though it is not a big deal because usually commands fail to apply due
> to operating on a wrong type of key. Like, sadd on a hash will result
> in error.
> But it is about fixing bugs in your own software :-)
>
>
>
>
>
> > However, Redis doesn't
> > support rollbacks. Every command in the M/E block is executed serially, so
> > also errors will just be returned. The only guarantee that M/E gives is
> > atomicity of the executed commands (all the ACID properties hold, by the
> > way).
> > I hope this clarifies things a bit.
> > Cheers,
> > Pieter
>

[Pieter Noordhuis]

This exact snippet will not work, however the general idea is correct. You can provide WATCH with N keys to watch, so you don't need multiple statements. If you perform a GET inside a MULTI-block, Redis will simply return "QUEUED". The general approach is that you WATCH the keys you are about to modify, you GET (or LRANGE, ZSCORE, ...) the values you need to modify and then update them inside the MULTI-block. The MULTI-block will not be executed if any of the WATCH'ed keys was modified since WATCH was issued. Also, EXEC implies an UNWATCH for all keys, so EXEC will always return in the same vanilla state before the first WATCH.

Cheers,

Pieter