Few queries on atomicity of requests
charles at rhosigma.org
Sun Jun 22 00:13:01 UTC 2008
>> Adding further metadata to the cache and changing the protocol
>> return it isn't really an option at this point, but it's easy to add
>> to the data in your application.
> Yeah, unless someone really needs it. It seems like this feature could
> be added to the current protocol easily enough just by adding an
> "expired" flag to the return data, and perhaps a command line switch to
> enable memcached to return expired data with a timestamp.
If you _really_ need this sort of meta data, there is an approach where
you can get this sort of information in the return data. Put it in the
value to begin with.
This is easy if you are storing fully-fledged objects that have already
been marshaled into something like JSON, etc... just add a member
holding the timestamp when it was stored. Likewise for any other sort
of meta data. This is natural since, as mentioned later in this thread,
memcached really shines when you are storing composited objects that
normally would be multiple requests (or a joined request) to a
relational data store.
If you are dealing with more "raw" types of data that _really_ need
piggy-backed meta data, you _could_ do something like wrap your memcache
client API get / set methods to handle a prepended header of your own
making (fixed width, magically delimited, faux-HTTP, etc, etc). This
could however become a maintenance headache if you are not careful.
More information about the memcached