Commit 69c94fbc authored by Kirill Smelkov's avatar Kirill Smelkov

X test that ZBlk objects can be actually removed from ZODB Connection cache...

X test that ZBlk objects can be actually removed from ZODB Connection cache and cause invalidation to be missed

____________________________________ test_bigfile_filezodb_vs_cache_invalidation ____________________________________

    def test_bigfile_filezodb_vs_cache_invalidation():
        root = dbopen()
        conn = root._p_jar
        db   = conn.db()
        conn.close()
        del root, conn

        tm1 = TransactionManager()
        tm2 = TransactionManager()

        conn1 = db.open(transaction_manager=tm1)
        root1 = conn1.root()

        # setup zfile with fileh view to it
        root1['zfile3'] = f1 = ZBigFile(blksize)
        tm1.commit()

        fh1 = f1.fileh_open()
        tm1.commit()

        # set zfile initial data
        vma1 = fh1.mmap(0, 1)
        Blk(vma1, 0)[0] = 1
        tm1.commit()

        # read zfile and setup fileh for it in conn2
        conn2 = db.open(transaction_manager=tm2)
        root2 = conn2.root()

        f2 = root2['zfile3']
        fh2 = f2.fileh_open()
        vma2 = fh2.mmap(0, 1)

        assert Blk(vma2, 0)[0] == 1 # read data in conn2 + make sure read correctly

        # now zfile content is both in ZODB.Connection cache and in _ZBigFileH
        # cache for each conn1 and conn2. Modify data in conn1 and make sure it
        # fully propagate to conn2.

        Blk(vma1, 0)[0] = 2
        tm1.commit()

        # still should be read as old value in conn2
        assert Blk(vma2, 0)[0] == 1
        # and even after virtmem pages reclaim
        # ( verifies that _p_invalidate() in ZBlk.loadblkdata() does not lead to
        #   reloading data as updated )
        ram_reclaim_all()
        assert Blk(vma2, 0)[0] == 1

        # FIXME: this simulates ZODB Connection cache pressure and currently
        # removes ZBlk corresponding to blk #0 from conn2 cache.
        # In turn this leads to conn2 missing that block invalidation on follow-up
        # transaction boundary.
        #
        # See FIXME notes on ZBlkBase._p_invalidate() for detailed description.
        conn2._cache.minimize()

        tm2.commit()                # transaction boundary for t2

        # data from tm1 should propagate -> ZODB -> ram pages for _ZBigFileH in conn2
>       assert Blk(vma2, 0)[0] == 2
E       assert 1 == 2

tests/test_filezodb.py:615: AssertionError
parent d1a579b2
...@@ -150,7 +150,7 @@ class ZBlkBase(Persistent): ...@@ -150,7 +150,7 @@ class ZBlkBase(Persistent):
# ZBigFile.blktab[blk] with another ZBlk created anew. # ZBigFile.blktab[blk] with another ZBlk created anew.
# #
# another example: a block may initially have no ZBlk attached (and # another example: a block may initially have no ZBlk attached (and
# thus it reads as 0). However when data in that block is changes - a # thus it reads as 0). However when data in that block is changed - a
# new ZBlk is created, but information that block data has to be # new ZBlk is created, but information that block data has to be
# invalidated is NOT correctly received by peers. # invalidated is NOT correctly received by peers.
# #
......
...@@ -601,6 +601,14 @@ def test_bigfile_filezodb_vs_cache_invalidation(): ...@@ -601,6 +601,14 @@ def test_bigfile_filezodb_vs_cache_invalidation():
ram_reclaim_all() ram_reclaim_all()
assert Blk(vma2, 0)[0] == 1 assert Blk(vma2, 0)[0] == 1
# FIXME: this simulates ZODB Connection cache pressure and currently
# removes ZBlk corresponding to blk #0 from conn2 cache.
# In turn this leads to conn2 missing that block invalidation on follow-up
# transaction boundary.
#
# See FIXME notes on ZBlkBase._p_invalidate() for detailed description.
conn2._cache.minimize()
tm2.commit() # transaction boundary for t2 tm2.commit() # transaction boundary for t2
# data from tm1 should propagate -> ZODB -> ram pages for _ZBigFileH in conn2 # data from tm1 should propagate -> ZODB -> ram pages for _ZBigFileH in conn2
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment