First, make sure you do a transaction.begin() (or transaction.abort())
before you view your database for a given operation. This will sync
invalidations for a given transaction, even if it will only be a read
transaction, and reset the MVCC view.
The partial-view behavior you describe sounds like it might have been
possible pre-MVCC, but seems pretty unlikely now, unless you are
committing after each individual insertion rather than after the
...Actually, looking through your code in newData, that appears to be
what you are doing: if the object is iterable, you recursively call
newData on the sub-elements, with a commit for each insertion. In
that case, it would be reasonable for a concurrent reader to get part
of the insertions while the writer continues to write. Because of
MVCC, the reader will not see the subsequent insertions until it makes
another transaction commit/abort/begin.
There are some various other oddities to my eye--why do a ``while`` on
the BTree insertion when you don't mutate the key?--but they don't
look like the cause of the behavior you describe.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org