Personal tools
Skip to content. | Skip to navigation
Persistent queues are simply queues that are optimized for persistency via the ZODB. They assume that the ZODB is using MVCC to avoid read conflicts. They attempt to resolve write conflicts so that transactions that add and remove objects simultaneously are merged, unless the transactions are trying to remove the same value from the queue. An important characteristic of these queues is that they do not expect to hold more than one reference to any given equivalent item at a time. For instance, some of the conflict resolution features will not perform desirably if it is reasonable for your application to hold two copies of the string "hello" within the same queue at once [1]. The module provides two flavors: a simple persistent queue that keeps all contained objects in one persistent object (Queue), and a persistent queue that divides up its contents into multiple composite elements (CompositeQueue). They should be equivalent in terms of API and so are mostly examined in the abstract in this document: we'll generate instances with a representative Queue factory, that could be either class. They only differ in an aspect of their write conflict resolution behavior.
Buildout Egg-Installation Recipe The egg-installation recipe installs eggs into a buildout eggs directory. It also generates scripts in a buildout bin directory with egg paths baked into them.
ZC Buildout recipe for creating test runners
Index intransitive and transitive n-ary relationships.
Post-rendering Resource Inclusion
This package provides a load balancer for WSGI applications that sorts requests into request classes and assigns requests of a given class to the same workers. The load balancer can benefit you if you have an application that: has too much load (or is too slow) to be handled by a single process, has a working set that is too large to fit in the caches used by your process, and there is a way to classify requests so that there is little overlap in the working sets of the various classes.
An easy way to create custom Zope 3 sources.
Programmable web browser for functional black-box testing of web applications
The thread-creation API provided by the Python threading module is annoying. :) This package provides a very simple thread-creation API that: Makes threads daemonic and allows daemonicity to be passed to the constructor. For example: zc.thread.Thread(mythreadfunc) Starts a daemonic thread named 'mythreadfunc' running mythreadfunc. Allows threads to be defined via decorators, as in: import zc.thread @zc.thread.Thread def mythread(): ... In the example above, a daemonic thread named mythread is created and started. The thread is also assigned to the variable mythread. You can control whether threads are daemonic and wether they are started by default: import zc.thread @zc.thread.Thread(daemon=False, start=False) def mythread(): ... After a thread finishes, you can get the return value of the target function from the thread's value attribute, or, if the function raises an exception, you can get the exception object from the thread's exception attribute. (This feature was inspired by the same feature in gevent greenlets.) There's also a Process constructor/decorator that works like Thread, but with multi-processing processes, and without the value and exception attributes.
Twist: Talking to the ZODB in Twisted Reactor Calls The twist package contains a few functions and classes, but primarily a helper for having a deferred call on a callable persistent object, or on a method on a persistent object. This lets you have a Twisted reactor call or a Twisted deferred callback affect the ZODB. Everything can be done within the main thread, so it can be full-bore Twisted usage, without threads. There are a few important "gotchas": see the Gotchas section below for details. The main API is Partial. You can pass it a callable persistent object, a method of a persistent object, or a normal non-persistent callable, and any arguments or keyword arguments of the same sort. DO NOT use non-persistent data structures (such as lists) of persistent objects with a database connection as arguments. This is your responsibility. If nothing is persistent, the partial will not bother to get a connection, and will behave normally.