My idea of fun is to combine existing patterns, producing a solution to more specialized problem than the original pattern specifications individually. I should probably get out more.

In this case, I was faced with the following problem: how to create a flexible, complex and multi-dimensional chain of Command Objects (a chain of commands and subcommands), that was executable top down over and over, without re-executing the same command twice for that chain. Operations should block the execution of their children on failure to complete. Children should be executed serial, and isolated from each others potential failure.

When faced with creating complex relations between objects of the same type, with operations to be executed on the underlying structure transparently, the Composite pattern can usually save the day. I created a mechanism to create a composite structure of any implementation of an abstract Command Object class.

Because I implemented Composite, I already had a mechanism to execute a Command and it's descendants in the order required.

Whether you're running your application as daemon or your using a caching server, homebrew (in that case you probably want to use the shmop extension, which will save you the trouble of creating a PHP script daemon) or third party such as Memcached, there is a limit to the amount of memory you can use.

You may want to cache some items practically indefinitely, like keeping a visitor's session for 6 months. Keeping the session in memory for that time is of course ludicrous. Also, should your daemon handling caching crash, or need a reboot, bye bye data. The solution to this is to implement multilevel caching strategy.

Take a look at the following sequence diagram, which illustrates getting an (old) item from cache.

If you know your Design Patterns, you'll recognize a tiny Chain of Responsibility pattern in this example. In essence, we compose a chain of two objects, breaking on the first object that can handle the request. If you look near the bottom of the diagram, you'll notice that after retrieving an item, it is moved to the top of the chain. This done under the assumption that the item will be used more often in this time frame. The item is placed at the top of the stack of the first cache, and will continue to placed there by the top level cache, each time it gets accessed. The stack has a fixed length, so adding new items to it will pop off the least frequently used. The handler will then put it in the next cache in the chain. This is a crude implementation of the LFU (Least Frequently Used) strategy, which doesn't work.

Hold on, did he say "which doesn't work"? Yes, I did. The problem with this approach is that once the top level is full, every new addition to it will cause both a get and a put operation. With a three level (or more) cache, you risk cascading put operations. There is no solution to this in a single-threaded environment (that I can think of), other than being lenient with the amount of space the top level cache can use, and let garbage collection 'enforce' the limit. That means we no longer have a hard limit, but it also means our caching mechanism is as fast as it possibly can be. It's still risky, especially running an application daemon. The following implementation should be regarded as 'food for thought', nothing more, nothing less.

Even in the best of applications, errors will occur. Zend Framework has a great feature to deal with uncaught exceptions: the error handler front controller plugin, or Zend_Controller_Plugin_ErrorHandler.

In this post a quick example (or maybe not so quick – if you're in a hurry, come back later) of how to implement a relatively simple 'error controller' using Zend Framework.