No locking the data down during the transaction? - Redis DB

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion No locking the data down during the transaction?
Received-SPF: pass (google.com: domain of josiah.carl...@gmail.com designates 209.85.220.54 as permitted sender) client-ip=209.85.220.54;
MIME-Version: 1.0
In-Reply-To: <CA+m_8J1vTkqKzOrKX4H1yqd453XTw=JWG9i=JQ+8Zdc04t8...@mail.gmail.com>
References: <CA+m_8J3TWTqk5T=hTMFH3mTUzaWhXFawguBSXcfnHKk5WK_...@mail.gmail.com>
	<ffdfc44f-b27a-45e9-8946-ff98b437da29@googlegroups.com>
	<CA+m_8J27HrXZZB4ubCMn7_cVn6wmUKkmTZBhwJ5=9HWdGtD...@mail.gmail.com>
	<CADcB0yjw41XaGUzL-cAZYVUJntDCi3sbFtRz4ZoHD8DHH-h...@mail.gmail.com>
	<CA+m_8J1vTkqKzOrKX4H1yqd453XTw=JWG9i=JQ+8Zdc04t8...@mail.gmail.com>
Date: Sun, 14 Oct 2012 00:02:55 -0700
Message-ID: <CADcB0yhzc73sfXjqHUD+tdxTYSS_jpF4uCAGJ=co1O-pUsB...@mail.gmail.com>
Subject: Re: No locking the data down during the transaction?
From: Josiah Carlson <josiah.carl...@gmail.com>
To: redis-db@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Oct 13, 2012 at 1:32 AM, Felix E. Klee <felix.k...@inka.de> wrote:
> On Sat, Oct 13, 2012 at 5:14 AM, Josiah Carlson
> <josiah.carl...@gmail.com> wrote:
>> Note that Node doesn't support WATCH/MULTI/EXEC transactions.
>
> What? As far as I understand the node_redis module, it just forwards
> commands to Redis. From the [node_redis documentation][1]:
>
> "`MULTI` commands are queued up until an `EXEC` is issued, and then all
> commands are run atomically by Redis."

I had a discussion here with a fellow who swore up and down that the
Node Redis client only used a single connection to Redis, so if you
wanted to do a WATCH/.../MULTI/.../EXEC, while you were waiting for
the GET result in a callback, someone else could hop in and run some
other commands on that same connection - which would mess up what you
were doing.

If Node lets you create multiple connections, then I withdraw my claim.

Also note that there is a fundamental difference between MULTI/EXEC.
MULTI/EXEC lets you do an atomic sequence of operations as if they
were 1. But WATCH/MULTI/EXEC lets you do this:
WATCH foo
x = GET foo
if foo < 3:
  UNWATCH
  return
MULTI
INCR foo
EXEC

You can also do that with Lua, but AFAIK, that sequence of operations
is not possible with the Node Redis libraries (unless you can use
multiple connections).

>> Also note that while there are many things that Lua does support,
>> there are some operations that Lua doesn't support that are possible
>> with WATCH/MULTI/EXEC transactions [...]
>>
>> I can list them out if you'd like.
>
> Just one, please. That could be enlightening.

1. Fetch data from Redis
2. Use the fetched data to fetch other data from a *different* Redis,
local cache, a database, or some other resource
3. When the secondary data has been fetched, combine the two pieces of
data and write back to Redis - failing if some other process has
already done the same

You can think of this as the explicit cache-update scenario. It is
easy with WATCH/MULTI/EXEC or higher-level locks. Not possible with
Lua, as you can't make remote requests (by design). There are a couple
other things that I mention in my book about why something like
WATCH/MULTI/EXEC or locks built on W/M/E or Lua are still necessary
(but that's in chapter 11, which won't be out for another 3 weeks or
so).

> By the way, I am using scripting for very simple and well constrained
> tasks. Example:

I'm glad you figured out how to do this with a single command :)

 - Josiah
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
