Memcached StorageService

[Marvin Addison]

> I believe the SP's memcache plugin implements it, by maintaining a record
> in the store for the context to track the associated keys.

By associated keys, I assume you mean one key holds a list of the keys
of all entries belonging to the context. Assuming that's correct I
wanted to avoid that for performance reasons as well as boundary
problems. I didn't want to worry about the edge case (probably
far-fetched) where adding an item to a list causes the data to exceed
1M (max default entry size) and the write fails. Of course you could
do a bucketized list where you break up list items among multiple keys
(index % numBuckets, for example), but I didn't think the complexity
was worth it. I'm happy to reconsider.

> I admit I still don't "get" how it provides HA given no replication

You're not alone. In any case I went to a fair amount of trouble to
describe the failure characteristics in a HA environment for the CAS
use case, which I think is relevant here as well:

http://jasig.github.io/cas/4.0.0/installation/Memcached-Ticket-Registry.html#high-availability-considerations

> I would like it in in the 3.0 package if we can get it there.

I'm certainly willing to work to reach that goal.

> Speaking of which, I've just been busy, but we had the formal vote on the
> PMC list to add you as a committer so I need to get you an account in svn
> and so forth, and then you can start checking in the CAS stuff and this if
> you're prepared to work on that.

That's great news! I'm absolutely ready to work on it.

Best,
M