Hi Kenneth.

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 aggregated insertion.

...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

Reply via email to