Arrow of time
Arrow of time

Bullet Cache use cases, Part 2: Data sharing

Share Tweet Share

In addition to simple data caching, there are some interesting advanced features made possible by Bullet Cache's unique features …

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:

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!


#1 Re: Bullet Cache use cases, Part 2: Data sharing

Added on 2012-02-07T20:56 by jgh

Is a port being worked on for FreeBSD for bullet cache?

Thanks!

#2 Re: Bullet Cache use cases, Part 2: Data sharing

Added on 2012-02-07T20:57 by Ivan Voras

Yes, I've already submitted it!

#3 Re: Bullet Cache use cases, Part 2: Data sharing

Added on 2012-04-06T20:25 by ...

Can tags be changed/modified in a single call?

Thanks andd good work!

#4 Re: Bullet Cache use cases, Part 2: Data sharing

Added on 2012-04-07T22:52 by Ivan Voras

Yes, but currently only as all-or-nothing: there is a call which replaces all tags of a record with another set of tags.


comments powered by Disqus