In addition to simple data caching, there are some interesting advanced features made possible by Bullet Cache's unique features. Data sharing between applications (or between application instances) is a very important one, especially for the PHP environment (and other CGI-like environments). This post is a part of series on Bullet Cache use cases.
Previously in the series of posts about Bullet Cache:
- Installation and testing
- The C API tutorial
- RC1 announcement
- Lessons leared in its development, 1.0 announcement
- Bullet Cache use cases, Part 1: Data caching with record tags
State-less Web application development environments such as the PHP have an inconvenient disadvantage: they do not have a simple, built-in method of sharing data across multiple invocations (or page loads) of a single Web application. In other words, their data is not persistent. This is somewhat solved by using HTTP sessions to persist important data, but sessions are slow and inconvenient for storing large amounts of data, and useless for storing and accessing truly global data (needed across all sessions). Cache servers are a way around this limitation: by storing data in a cache server, all application invocations can access the same data and have the same guarantees of its freshness.
Bullet Cache offers some additional features.
A shared stack
All tagged records are by default a part of a virtual stack. Such stacks are referenced by the record tag key-value pairs (each tag key-value pair identifies a different stack). An application can insert records either the usual way, or by using the "TSTACK" (tag stack) API which auto-generates record keys.
An advanced application of this principle is in creating "message queues", where the records are pushed onto the stack and retrieved from the stack by different applications.
A distributed lock manager
Bullet Cache implenents a range of atomic operations which can be used as a basis of a distributed lock manager. The record values can be atomically manipulated in a way which makes them behave as mutexes or semaphores.
Simple implementations of such a lock manager are not robust (against the disappearance / crash of an application which has acquired locks) but when the usage of the record tags make it is easy to implement a "cleanup" operation for dead locks.
Vote on the Bullet Cache's future development!
There are several directions in which Bullet Cache could take off in the future. Here is your chance to vote for a favourite feature!