[Zodb-checkins] CVS: Zope3/src/zodb/storage - bdbfull.py:1.27

Barry Warsaw barry at zope.com
Wed Jul 2 17:21:42 EDT 2003


Update of /cvs-repository/Zope3/src/zodb/storage
In directory cvs.zope.org:/tmp/cvs-serv13685

Modified Files:
	bdbfull.py 
Log Message:
_dopack(): Update the comment and protect the commit lock with a
try/finally.


=== Zope3/src/zodb/storage/bdbfull.py 1.26 => 1.27 ===
--- Zope3/src/zodb/storage/bdbfull.py:1.26	Wed Jul  2 16:00:27 2003
+++ Zope3/src/zodb/storage/bdbfull.py	Wed Jul  2 16:21:35 2003
@@ -1343,30 +1343,33 @@
         self.log('pack finished')
 
     def _dopack(self, t, gc):
-        # t is a TimeTime, or time float, convert this to a TimeStamp object,
-        # using an algorithm similar to what's used in FileStorage.  We know
-        # that our transaction ids, a.k.a. revision ids, are timestamps.
+        # BAW: should a pack time in the future be a ValueError?  When ZEO is
+        # involved, t could come from a remote machine with a skewed clock.
+        # Jim wants us to believe t if it's "close", but our algorithm
+        # requires synchronicity between the calculate of the pack time and
+        # the timestamps used in serial numbers.
         #
-        # BAW: should a pack time in the future be a ValueError?  We'd have to
-        # worry about clock skew, so for now, we just set the pack time to the
-        # minimum of t and now.
+        # If a transaction is currently in progress, wait for it to finish
+        # before calculating the pack time, by acquiring the commit lock.
+        # This guarantees that the next transaction begins after the pack
+        # time so that any objects added in that transaction will have a
+        # serial number greater than the pack time.  Such objects will be
+        # completely ignored for packing purposes.
         #
-        # If a transaction is currently in progress, wait for it to finish.
-        # If we don't hold the commit lock while computing pack time, then,
-        # for example:  a transaction is currently in progress, and we
-        # pack to "now".  After marking the root-reachable objects but
-        # before sweeping, a store comes in adding a new object, but not
-        # yet a store that makes the new object reachable from the root.
-        # Then the new object is in the collection of all objects, but
-        # doesn't appear to be reachable from the root, and has a time
-        # before the pack time, so it's collected as garbage.  Holding
-        # the commit lock while computing the pack time ensures that the
-        # next transaction begins after the pack time, implying that
-        # nothing it may add will be treated as garbage.
+        # If we don't do this, then it would be possible for some of the
+        # current transaction's objects to have been stored with a serial
+        # number earlier than the pack time, but not yet linked to the root.
+        # Say that thread 1 starts a transaction, and then thread 2 starts a
+        # pack.  Thread 2 then marks the root-reachable objects, but before
+        # sweeping, object B is stored by thread 1.  If the object linking B
+        # to the root hasn't been stored by the time of the sweep, B will be
+        # collected as garbage.
         self._commit_lock_acquire()
-        packtime = min(t, time.time())
-        packtid = timeStampFromTime(packtime).raw()
-        self._commit_lock_release()
+        try:
+            packtime = min(t, time.time())
+            packtid = timeStampFromTime(packtime).raw()
+        finally:
+            self._commit_lock_release()
         # Collect all revisions of all objects earlier than the pack time.
         self._lock_acquire()
         try:




More information about the Zodb-checkins mailing list