[ZODB-Dev] [Enhancement Proposal] Memory size limited Cache

[Jim Fulton]

Dieter Maurer wrote:
> Jim Fulton wrote at 2006-10-6 17:04 -0400:
...
>> Or consider object activation and deactivation. If a ghost is
>> shared among multiple threads, then __setstate__ could
>> be called from separate threads.
> 
> But, why should this be a problem? They would install the same
> state.

Because __setstate__ is written assuming that no other thread is
calling it.  Threaded programming is tricky.  Code designed for a
threaded environment has to take the possibility of of multiple
simultaneous calls into account.  Traditionally, persistent object
implementors haven't had to do that.

>> And of course, there's the possibility that buggy software
>> might try to mutate the objects.  How would you prevent it?
> 
> The special read-only connection with shared cache would raise 
> an exception instead of joining the transaction.

That's too late.

> Of course, other threads might already have been affected
> (e.g. in the example above of modifying non-persistent data).
> But, bugs can have nasty effects....

ZODB applications count on isolation.  IMO, it isn't acceptable
to give up on the isolation guarantee.

>> You couldn't wait until commit if there was the possibility that
>> other threads might see the errant changes.
> 
> In most cases (when an attribute of a persistent object is changed),
> we could be able to detect the forbidden modification
> before it happens:
> 
>   The modification goes through "Persistent.__setattr__"
>   which informs the associated connection which joins the transaction.
>   Thus, if the connection does not want that its objects are changed,
>   it raises an exception instead of joining the transaction.

Good point. That helps.

What if the exception is swallowed?  What would you do? Reload the state?
Maybe this could be made to work. I don't know.

> This fails for:
> 
>   * volatile attributes -- I have no easy solution

Conceivably the persistence machinery could disallow
assignments to _v_ attrs.

...

My intuition is still that sharing objects between threads will
introduce a host of subtle bugs.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org