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

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 Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to