Optimistic locking with redis cluster

[Tornike T]

Hello Guys, 

last several days researching and reading documentations to reach correct way of optimistic locking with redis cluster.

With a single note WATCH, MULTI, EXEC is perfect but how can i reach this funcitionality within cluster, or is there any custom implementations;

Currently using Lettuce library for Java.

Thanks

[Marc Gravell]

When using cluster, if you need a single operation to son multiple keys, you should ensure they are in the same slot, by using hash tags; for example "{some prefix}/foo" and "{some prefix}/bar" will always be in the same slot, calculated using the value in the braces.

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/redis-db/f44e2836-7fd8-4a30-92fd-0681ccc048ff%40googlegroups.com.

[Tornike T]

Thanks for reply, isn't there any general solution without working with nodes, for example, to get data with score and before update check if score is same, else throw exception.

To view this discussion on the web visit https://groups.google.com/d/msgid/redis-db/CAF95VAzSekgviTZSdvTsk1PL-WJpK0VnVMKSP9M9aJSwz-Vpig%40mail.gmail.com.

[Marc Gravell]

Absolutely you can do assertion based updates  **on the same node**, in the same ways that you would on non-cluster, specifically:

1. using a Lua script that verifies your assertions before making the change; Lua scripts run without being interleaved with competing connections, so there is no race condition

2. using a WATCH / {assert} / MULTI / {apply} / EXEC / {check outcome} approach (WATCH / {assert} / UNWATCH if the assert fails) - this is much more complex, though; I'd lean towards Lua!

The emphasis, though, is that **any** multi-key operation in cluster (that needs to be effectively atomic) should use hash tags to ensure that the related keys are on the same slot; otherwise there is no inbuilt way to coordinate it.

Alternatively, you could implement eventual consistency yourself *without* relying on server atomicity.

To view this discussion on the web visit https://groups.google.com/d/msgid/redis-db/CAGadP%3DUWKoJioGndTY9Z7tDe1APhm9G%3D%2BQQ66hUBkPZSa%3DrsPg%40mail.gmail.com.

--

Regards,

Marc