This patch deals with the following scenarios, which would ended up cleaning the inTransaction prematurely: 1. UNWATCH after MULTI t = multi t.unwatch 2. WATCH, MULTI (with keys) t = watch t.multi("foobar") t.unwatch 3 . MULTI + WATCH t = multi t.watch # this is invalid, but will change the _unwatch_cc to a function that would clear the inTransaction state I've also dropped a couple more tests, notably testing WATCH with ConnectionPool.
This commit enables users to use the following pattern: WATCH GET MULTI EXEC/DISCARD The old behavior have been kept intact, i.e., the multi function continues to accept a list of keys to watch prior issuing the watch command, although I believe this use should be deprecated. The watch command may also be used standalone. In this case, users should make use of the watch command to clear the `inTransaction' state. Some examples (the following assumes inlineCallbacks): # 1. Using watch/unwatch tx = yield conn.watch(...) ... yield tx.unwatch() # 2. Using watch/multi tx = yield conn.watch(...) ... yield tx.multi() ... yield tx.commit() # 3. Using watch only tx = yield conn.multi(...) ... yield tx.commit() # 4. All together: tx = yield conn.watch(...) ... yield tx.multi() ... yield tx.unwatch() # this will not clear # the `inTransaction` state ... yield tx.commit()
Apparently, the txredisapi ci server is running with a pretty old version of Twisted?
…back() for lost connections (and other errors)
…o we can reuse the connection-wrangling logic in RedisFactory
Deferred returned by these methods was waiting for data to appear in replyQueue which never happened. Fixed this by submitting message type name to replyQueue if the type is anything but 'message'.