[Zope3-checkins] CVS: Zope3/src/zodb/storage - bdbminimal.py:1.24

[Barry Warsaw]

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

Modified Files:
	bdbminimal.py 
Log Message:
pack(): Minor re-formatting of Tim's good comment.


=== Zope3/src/zodb/storage/bdbminimal.py 1.23 => 1.24 ===
--- Zope3/src/zodb/storage/bdbminimal.py:1.23	Mon Jun 30 18:28:22 2003
+++ Zope3/src/zodb/storage/bdbminimal.py	Mon Jun 30 18:41:21 2003
@@ -390,25 +390,27 @@
         # Before setting the packing flag to true, acquire the storage lock
         # and clear out the packmark table, in case there's any cruft left
         # over from the previous pack.
-        # Caution:  this used to release the commit lock immediately after
-        # clear_packmark (below) was called, so there was a small chance
-        # for transactions to commit between the packing phases.  This
-        # suffered rare races, where packing could (erroneously) delete
-        # an active object.  Since interleaving packing with commits
-        # is thought to be unimportant for minimal storages, the easiest
-        # (by far) fix is to hold the commit lock throughout packing.
-        # Details:  Suppose the commit lock is released after clearing
-        # packmark.  Suppose a transaction gets thru dostore before
-        # marking begins.  Then because self._packing is True, _dostore()
-        # adds the stored oids to _packmark.  But _mark() uses _packmark
-        # as a list of *chased* oids, not as a list of oids to *be* chased.
-        # So the oids added to _packmark by _dostore() don't get chased by
-        # _mark(), and anything they reference (that isn't referenced by
-        # something else too) is considered to be trash.  Holding the
-        # commit lock during all of packing makes it impossible for
-        # self._packing to be True when in _dostore() or _docommit(), so
-        # those never add anything to _packmark, and only the correct
-        # oid-chasing code in _mark() populates _packmark.
+        #
+        # Caution: this used to release the commit lock immediately after
+        # clear_packmark (below) was called, so there was a small chance for
+        # transactions to commit between the packing phases.  This suffered
+        # rare races, where packing could (erroneously) delete an active
+        # object.  Since interleaving packing with commits is thought to be
+        # unimportant for minimal storages, the easiest (by far) fix is to
+        # hold the commit lock throughout packing.
+        #
+        # Details: Suppose the commit lock is released after clearing
+        # packmark.  Suppose a transaction gets through _dostore() before
+        # marking begins.  Then because self._packing is True, _dostore() adds
+        # the stored oids to _packmark.  But _mark() uses _packmark as a list
+        # of *chased* oids, not as a list of oids to *be* chased.  So the oids
+        # added to _packmark by _dostore() don't get chased by _mark(), and
+        # anything they reference (that isn't referenced by something else
+        # too) is considered to be trash.  Holding the commit lock during all
+        # of packing makes it impossible for self._packing to be True when in
+        # _dostore() or _docommit(), so those never add anything to _packmark,
+        # and only the correct oid-chasing code in _mark() populates
+        # _packmark.
         self._commit_lock_acquire()
         try:
             # We have to do this within a Berkeley transaction