[Zodb-checkins] SVN: ZODB/branches/3.10/src/ - Removed a missfeature that can cause performance problems when using

Jim Fulton jim at zope.com
Tue Oct 26 17:25:05 EDT 2010


Log message for revision 117936:
  - Removed a missfeature that can cause performance problems when using
    an external garbage collector with ZEO.  When objects were deleted
    from a storage, invalidations were sent to clients. This makes no
    sense.  It's wildly unlikely that the other connections/clients have
    copies of the garbage.  In normal storage garbage collection, we
    don't send invalidations. There's no reason to send them when an
    external garbage collector is used.
  

Changed:
  U   ZODB/branches/3.10/src/CHANGES.txt
  U   ZODB/branches/3.10/src/ZEO/StorageServer.py
  U   ZODB/branches/3.10/src/ZEO/tests/testZEO.py

-=-
Modified: ZODB/branches/3.10/src/CHANGES.txt
===================================================================
--- ZODB/branches/3.10/src/CHANGES.txt	2010-10-26 21:20:04 UTC (rev 117935)
+++ ZODB/branches/3.10/src/CHANGES.txt	2010-10-26 21:25:05 UTC (rev 117936)
@@ -17,6 +17,14 @@
 
   https://bugs.launchpad.net/zodb/+bug/665452
 
+- Removed a missfeature that can cause performance problems when using
+  an external garbage collector with ZEO.  When objects were deleted
+  from a storage, invalidations were sent to clients. This makes no
+  sense.  It's wildly unlikely that the other connections/clients have
+  copies of the garbage.  In normal storage garbage collection, we
+  don't send invalidations. There's no reason to send them when an
+  external garbage collector is used.
+
 3.10.0 (2010-10-08)
 ===================
 

Modified: ZODB/branches/3.10/src/ZEO/StorageServer.py
===================================================================
--- ZODB/branches/3.10/src/ZEO/StorageServer.py	2010-10-26 21:20:04 UTC (rev 117935)
+++ ZODB/branches/3.10/src/ZEO/StorageServer.py	2010-10-26 21:25:05 UTC (rev 117936)
@@ -607,8 +607,6 @@
             raise
         except Exception, err:
             self._op_error(oid, err, 'delete')
-        else:
-            self.invalidated.append(oid)
 
         return err is None
 

Modified: ZODB/branches/3.10/src/ZEO/tests/testZEO.py
===================================================================
--- ZODB/branches/3.10/src/ZEO/tests/testZEO.py	2010-10-26 21:20:04 UTC (rev 117935)
+++ ZODB/branches/3.10/src/ZEO/tests/testZEO.py	2010-10-26 21:25:05 UTC (rev 117936)
@@ -1196,56 +1196,6 @@
     False
     """
 
-def delete_object_multiple_clients():
-    """If we delete on one client, the delete should be reflected on the other.
-
-    First, we'll create an object:
-
-    >>> addr, _ = start_server()
-    >>> db = ZEO.DB(addr)
-    >>> conn = db.open()
-    >>> conn.root()[0] = conn.root().__class__()
-    >>> transaction.commit()
-    >>> oid = conn.root()[0]._p_oid
-
-    We verify that we can read it in another client, which also loads
-    it into the client cache.
-
-    >>> cs = ClientStorage(addr)
-    >>> p, s = cs.load(oid)
-
-    Now, we'll remove the object:
-
-    >>> txn = transaction.begin()
-    >>> db.storage.tpc_begin(txn)
-    >>> db.storage.deleteObject(oid, s, txn)
-    >>> db.storage.tpc_vote(txn)
-    >>> db.storage.tpc_finish(txn)
-
-    And we'll get a POSKeyError if we try to access it:
-
-    >>> db.storage.load(oid) # doctest: +ELLIPSIS
-    Traceback (most recent call last):
-    ...
-    POSKeyError: ...
-
-    We'll wait for our other storage to get the invalidation and then
-    try to access the object. We'll get a POSKeyError there too:
-
-    >>> tid = db.storage.lastTransaction()
-    >>> forker.wait_until(
-    ...    'cs has caught up',
-    ...    lambda : cs.lastTransaction() == tid)
-    >>> cs.load(oid) # doctest: +ELLIPSIS
-    Traceback (most recent call last):
-    ...
-    POSKeyError: ...
-
-    >>> db.close()
-    >>> cs.close()
-    """
-
-
 def open_convenience():
     """Often, we just want to open a single connection.
 



More information about the Zodb-checkins mailing list