paste.registry – Manage thread-local request-specific objects

Registry for handling request-local module globals sanely

Dealing with module globals in a thread-safe way is good if your application is the sole responder in a thread, however that approach fails to properly account for various scenarios that occur with WSGI applications and middleware.

What is actually needed in the case where a module global is desired that is always set properly depending on the current request, is a stacked thread-local object. Such an object is popped or pushed during the request cycle so that it properly represents the object that should be active for the current request.

To make it easy to deal with such variables, this module provides a special StackedObjectProxy class which you can instantiate and attach to your module where you’d like others to access it. The object you’d like this to actually “be” during the request is then registered with the RegistryManager middleware, which ensures that for the scope of the current WSGI application everything will work properly.

Example:

#yourpackage/__init__.py

from paste.registry import RegistryManager, StackedObjectProxy
myglobal = StackedObjectProxy()

#wsgi app stack
app = RegistryManager(yourapp)

#inside your wsgi app
class yourapp(object):
    def __call__(self, environ, start_response):
        obj = someobject  # The request-local object you want to access
                          # via yourpackage.myglobal
        if environ.has_key('paste.registry'):
            environ['paste.registry'].register(myglobal, obj)

You will then be able to import yourpackage anywhere in your WSGI app or in the calling stack below it and be assured that it is using the object you registered with Registry.

RegistryManager can be in the WSGI stack multiple times, each time it appears it registers a new request context.

Performance

The overhead of the proxy object is very minimal, however if you are using proxy objects extensively (Thousands of accesses per request or more), there are some ways to avoid them. A proxy object runs approximately 3-20x slower than direct access to the object, this is rarely your performance bottleneck when developing web applications.

Should you be developing a system which may be accessing the proxy object thousands of times per request, the performance of the proxy will start to become more noticeable. In that circumstance, the problem can be avoided by getting at the actual object via the proxy with the _current_obj function:

#sessions.py
Session = StackedObjectProxy()
# ... initialization code, etc.

# somemodule.py
import sessions

def somefunc():
    session = sessions.Session._current_obj()
    # ... tons of session access

This way the proxy is used only once to retrieve the object for the current context and the overhead is minimized while still making it easy to access the underlying object. The _current_obj function is preceded by an underscore to more likely avoid clashing with the contained object’s attributes.

NOTE: This is highly unlikely to be an issue in the vast majority of cases, and requires incredibly large amounts of proxy object access before one should consider the proxy object to be causing slow-downs. This section is provided solely in the extremely rare case that it is an issue so that a quick way to work around it is documented.

Module Contents

class paste.registry.StackedObjectProxy(default=<class 'paste.registry.NoDefault'>, name='Default')

Track an object instance internally using a stack

The StackedObjectProxy proxies access to an object internally using a stacked thread-local. This makes it safe for complex WSGI environments where access to the object may be desired in multiple places without having to pass the actual object around.

New objects are added to the top of the stack with _push_object while objects can be removed with _pop_object.

class paste.registry.Registry

Track objects and stacked object proxies for removal

The Registry object is instantiated a single time for the request no matter how many times the RegistryManager is used in a WSGI stack. Each RegistryManager must call prepare before continuing the call to start a new context for object registering.

Each context is tracked with a dict inside a list. The last list element is the currently executing context. Each context dict is keyed by the id of the StackedObjectProxy instance being proxied, the value is a tuple of the StackedObjectProxy instance and the object being tracked.

class paste.registry.RegistryManager(application, streaming=False)

Creates and maintains a Registry context

RegistryManager creates a new registry context for the registration of StackedObjectProxy instances. Multiple RegistryManager’s can be in a WSGI stack and will manage the context so that the StackedObjectProxies always proxy to the proper object.

The object being registered can be any object sub-class, list, or dict.

Registering objects is done inside a WSGI application under the RegistryManager instance, using the environ['paste.registry'] object which is a Registry instance.

class paste.registry.StackedObjectRestorer

Track StackedObjectProxies and their proxied objects for automatic restoration within EvalException’s interactive debugger.

An instance of this class tracks all StackedObjectProxy state in existence when unexpected exceptions are raised by WSGI applications housed by EvalException and RegistryManager. Like EvalException, this information is stored for the life of the process.

When an unexpected exception occurs and EvalException is present in the WSGI stack, save_registry_state is intended to be called to store the Registry state and enable automatic restoration on all currently registered StackedObjectProxies.

With restoration enabled, those StackedObjectProxies’ _current_obj (overwritten by _current_obj_restoration) method’s strategy is modified: it will return its appropriate proxied object from the restorer when a restoration context is active in the current thread.

The StackedObjectProxies’ _push/pop_object methods strategies are also changed: they no-op when a restoration context is active in the current thread (because the pushing/popping work is all handled by the Registry/restorer).

The request’s Registry objects’ reglists are restored from the restorer when a restoration context begins, enabling the Registry methods to work while their changes are tracked by the restorer.

The overhead of enabling restoration is negligible (another threadlocal access for the changed StackedObjectProxy methods) for normal use outside of a restoration context, but worth mentioning when combined with StackedObjectProxies normal overhead. Once enabled it does not turn off, however:

o Enabling restoration only occurs after an unexpected exception is detected. The server is likely to be restarted shortly after the exception is raised to fix the cause

o StackedObjectRestorer is only enabled when EvalException is enabled (not on a production server) and RegistryManager exists in the middleware stack

paste.registry.make_registry_manager(app, global_conf)

Creates and maintains a Registry context

RegistryManager creates a new registry context for the registration of StackedObjectProxy instances. Multiple RegistryManager’s can be in a WSGI stack and will manage the context so that the StackedObjectProxies always proxy to the proper object.

The object being registered can be any object sub-class, list, or dict.

Registering objects is done inside a WSGI application under the RegistryManager instance, using the environ['paste.registry'] object which is a Registry instance.