[ZODB-Dev] Can __setstate__ trigger an RCE?

[Jeremy Hylton]

On Tue, 2004-07-06 at 14:07, Christian Robottom Reis wrote:
> I'm still trying to track down a problem that occurs with read conflicts
> in IndexedCatalog when using ZODB without MVCC enabled. The issue is
> that occasionally, I find in my client logs a conflict error on a
> OOBucket instance stored as _change_buffer in Catalog persistent
> instances. The interesting part is that the Catalog has the following
> code as part of its __setstate__ method:
> 
>     def __setstate__(self, state):
>         # Load the _change_buffer to ensure we have its state and avoid
>         # a ReadConflictError when handling it
>         list(self._change_buffer.items())
> 
> which should AFAIK load all the _change_buffer items and therefore avoid
> any potential conflict there.

>From the traceback, it looks like it's getting the read conflict as a
result of this attempt to load all the buckets in _change_buffer.

> What's dogging me is that __setstate__ *itself* is generating RCEs, and
> this is something I don't understand. Shouldn't we be inherently
> protected from RCEs when __setstate__ is called, given that we're at a
> transaction boundary already?

No.  The transaction boundary is a boundary, not a span.  Code that is
reading any object is always operating within some transaction context. 
Since the commit has not yet finished, you're still inside the
transaction that started when you called commit().  (I assume that what
you meant was that someone had called commit().)

The read conflict means that one of the buckets was modified after your
transaction started.

Jeremy