Changes between Version 14 and Version 15 of TracDev/Proposals/CacheInvalidation

Timestamp:

Mar 27, 2009, 4:56:55 PM (15 years ago)

Author:

Christian Boos

Comment:

suggested fix for invalidate()

TracDev/Proposals/CacheInvalidation

@@ -162 +162 @@
      is not thread-safe (again for the same reason that a SELECT doesn't start a transaction)
      so we should rather do `try INSERT `, `except UPDATE`.
-     - That's what I tried first, but the error due to the `INSERT` rolled back the whole transaction. I'll have to find a way to do this in a single statement.
+     - That's what I tried first, but the error due to the `INSERT` rolled back the whole transaction. I'll have to find a way to do this in a single statement. 
+       - Hm right, that can be problematic. So what about this:
+         {{{
+#!python
+    cursor.execute("SELECT generation FROM cache WHERE key=%s",
+                   (key,)) 
+    do_update = cursor.fetchone()
+    if not do_update:
+        try: 
+            cursor.execute("INSERT INTO cache VALUES (%s, %s)",
+                           (key, 0))
+        except Exception:
+            do_update = True
+    if do_update:
+            cursor.execute("UPDATE cache SET generation=generation+1" 
+                           "WHERE key=%s", (key,))
+           }}}
+         If we were in a transaction, then I suppose the SELECT/INSERT
+         sequence can't fail. Conversely, if it fails, then we were
+         ''not'' in a transaction, and we can follow-up with an UPDATE
+         to recover from the failed INSERT.
+         
    Both points are minor and could be done on trunk.
  - What to do next?