2. Presentation A simple & pragmatic workaround for a complex problem A heavy flow of content publishing can lead to LOCK timeouts Lock wait timeout exceeded; try restarting transaction. Query: UPDATE ezcontentobject_tree SET modified_subnode=1291901964 WHERE node_id IN The transaction is too big It can't easily be reduced Let's reverse the issue , and limit what we ask to the DB Send publishing operations to a centralized, controlled queue Have the queue process publishing operations in background
3. Under the hood Quick dive into the system's guts Settings: content.ini Feature is disabled by default (BC) The queue size is configured here Publishing done through a real system daemon with forks Minimal memory usage : one process publishes one object, and dies User interaction is done through content/queued.tpl , a new view/template: This template updates itself using ezjscore/ AJAX It is fully overrideable (class, section, id, etc) Feature is only enabled for content/edit
4. Better user feedback Cronjob based workflows won't silently interrupt. Custom feedback is possible ! After publishing, one can access the (newly) published object No more long waiting time when publishing Queued objects are visible as pending items Benefits There are extra bonuses ! 01/27/11