[Zope] persistent object with non-persistent attributes

[Paul Winkler]

On Tue, Mar 04, 2003 at 10:50:34AM -0800, sean.upton@uniontrib.com wrote:
> Thinking aloud: ...so myNonZopeClass instances need to be a singleton-like
> thing, with some sort of mutex-ish of lock to prevent other instances from
> being constructed?

singletons seem to be more easily handled by other pythonic
approaches, as you go on to say ...  

> I wonder if there is a way to throw an exception on
> construction of a myNonZopeClass instance if another Zope thread has an
> instance.  Perhaps you could keep an external boolean lock variable in a
> module-level global accessible to all threads, but it might just be easier
> to follow Toby's suggestion and just see if you can keep your myNonZopeClass
> instance object in a module-level global, and just keep a reference to it in
> a _v_ attribute?  I've never tried anything like this, might something like
> this possibly work?

I'd think so.

Another approach to consider is "Borg" aka "Monostate" aka "all your state are
belong to us".
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66531

yet another approach is to use a class instead of a module,
e.g. http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/113657

None of these address the issues of access control, as Alex Martelli's
comments on Borg make clear:

""" threading, Alex Martelli, 2001/10/15
Threading issues really have little to do with Highlander vs Borg (or
Singleton vs Monostate if you prefer boring names:-). In Python, it's
simplest to devote a thread to handling a bunch of resources that need
to be serialized (no matter whether they're wrapped into one or more
objects of whatever type), with a Queue of requests on which the
devoted-thread (Guardian thread) always sleeps working for requests. All
access by working threads to the guardian thread and the resources it
protects is by posting to the guardian queue a tuple (response-queue,
callable, args, kwds) followed by waiting on the response-queue. Why
people would want to conflate this important idiom with the equally
important and unrelated idiom of state sharing is a mystery to me, as
they work just as well together or separately. What's the contrary of
"divide and conquer" -- "conflate and suffer"?-)
"""

hmmm, i can't quite envision how you'd do this "guardian thread" business
in a Zope product, or if there's a better equivalent.

-- 

Paul Winkler
http://www.slinkp.com