questions about errata for listing 6.9

[Deleted user]

In errata for listing 6.9 (http://www.manning.com/carlson/excerpt_errata.html), it's said "Code bug: there is an extra pipe.watch(buyer) call that is unnecessary, which can be removed."

1. If this can be removed, I think the try ... except redis.exceptions.WatchError (https://github.com/josiahcarlson/redis-in-action/blob/master/python/ch06_listing_source.py#L203) and pipe.unwatch() (https://github.com/josiahcarlson/redis-in-action/blob/master/python/ch06_listing_source.py#L194) can be removed, too. Is that correct?

2. Could you explain more about why this can be removed?
   My understanding is there's an assumption that purchasing items is the only way to reduce the buyer's funds. If this assumption stands, the market-level lock already makes sure no multiple purchases occur at the same time and therefore it's not necessary to watch the buyer info.

3. If fine-grained lock is used, it's still necessary to watch this, isn't it?

[Josiah Carlson]

There are several improvements that can be made in that block of code. Removing the pipe.watch(buyer) is just the part that makes it work correctly.

Removing the try: ... except ... section and pipe.unwatch() are two improvements that are possible. It's also possible to remove the unnecessary while loop and a few other parts.

Your understanding is mostly correct. The other part is that when you have a transactional pipeline with the Python Redis client (you get them with conn.pipeline(True) a little ways up), calling pipe.watch(...) puts the client in an interactive state until you call pipe.multi(). You can compare the watch/multi/exec version here with the non-watch version here . But the long story short is that if the only way money is reduced is via purchases, and only one person can purchase at a time (thanks to the marketplace lock), then you don't need to watch the user's balance for (negative) changes.

Regarding the fine-grained lock; yes, the watch is still necessary. But that's because multiple purchases can occur simultaneously due to the item-level locks, so we need to pay attention to balances. I can't recall whether I tested contention here as part of the benchmarks, and I'm not able to find the benchmarking code I used to produce the charts. The real win is when we get to chapter 11 and do away with watch and locks.

I'll clean up listing 6.9 and 7.15 either tonight or tomorrow and get the errata updated. Thank you for the comments and questions :)

[Josiah Carlson]

I've update the source repository and have sent the errata to the publisher for updating.

[Deleted user]

Thanks a lot!

[Josiah Carlson]

Closing this way late because this is already up in the errata listing. Thank you again for reporting the issue :)