[Zope-Coders] MaintenanceMode of Proposals

[Matthew T. Kromer]

http://dev.zope.org/Wikis/DevSite/Proposals/MaintenanceMode


Rob Page and I have talked about puting a change into the proposed Zope 
2.6 features list.  Here is the proposal:


CONTACT
Matt Kromer

PROBLEM
Zope occasionally needs to be quiesced to perform some task, such as 
rebuilding a catalog. If other users are using the Zope site, or are 
writing to the database, this can have very negative impacts on the 
maintenance. In a real-world situation, a catalog reindex that should 
have taken 90 seconds to complete was never able to finish because of 
conflicts with other catalog updates.

PROPOSED SOLUTION
The control panel will gain a new "Maintenance Activity" control, with 
the following three positions: "Normal mode," "Concurrent (R/O)," and 
"Exclusive" representing that the system is ether operating normally (no 
maintenance), is allowing read-only connections from non-maintainers, or 
is only allowing connections from the maintainer. The maintenance 
activity state will be stored as an attribute on the application object, 
and thus will be shared through a ZEO cluster.

A maintainer shall be the user who caused the system to go into 
maintenance mode; this represents someone with Manager access to the 
control panel. Once the system enters maintenance mode, only the the 
maintainer or the emergency user can cause it to change state.

Any access to the system in "Concurrent (R/O)" maintenance by someone 
other than the maintainer or the emergency user will be allowed to run, 
but at transaction commit time any changes will be aborted; no write 
activity will be allowed to the database.

Any access to the system in "Exclusive" maintenance by someone other 
than the maintainer or the emergency user will be aborted immediately by 
raising a System error.

The publisher, during initial invocation of a request, will determine 
the maintenance mode and apply restrictions to the request, as 
necessary. During the course of a retry of a transaction, the 
maintenance state will be refetched.

FORSEEN RISKS

    * Concurrent mode may inadvertently allow changes that are not
      detectable at the time of transaction commit (ie changes that do
      not participate with the transaction manager, such as invocation
      of external methods, etc.)
    * Long running transactions started before the maintenance state is
      changed will not pick up the new state.
    * The scope of the maintenance is system-wide. It would be
      desireable in some instances to restrict it to certain paths only.
    * It may be impossible to implement a reliable change detector for
      some transactions in "concurrent" mode. The alternative of having
      a transaction always vote "no" at commit time would raise an error
      rather than allowing normal read activity to complete.
    * It is unclear if maintenance should also implictly or explicitly
      restrict the number of application threads, to prevent ANY other
      application thread from running.

DELIVERABLES

Modifications to Zope's Publisher and Control Panel, which implement the 
maintenance filter.