On Jan 28, 9:39 pm, rspadim <rspa...@gmail.com> wrote: > hi guys, there's a async replication project (repcached) that is very > interesting, could we implement it in main source code? at compile > time we could select from repcached or memcached > could we make it sync and/or async?http://repcached.sourceforge.net/
Memcached has been slow to get releases out, but that is based on a very, very old version. In the areas we've been doing development, we've created APIs for allowing engines to build replication protocols (and we've got engines in production using them). > =========================================================================== > ====== > there's some non volatile solutions too that's very interesting > (memcachedb), for low memory computers we can use disk > could we implement it in main source code too?http://memcachedb.org/ Same as above. > =========================================================================== > ====== > another, now !NEW! feature... > > i was looking for a *DISTRIBUTED LOCK MANAGER*, but i only found > kernel linux lock manager, that's based on file system (flock) > could we implement a lock manager at memcached? A distributed lock manager requires multiple servers to have a shared knowledge of resources to make agreements on who is owning shared resources. This is quite a bit away from what memcached can do. I've written network lock managers before (hand-waving distributed features by showing where I'd plug them in, but I didn't need them where I was). danga has a real distributed lock management toolkit called ddlockd where the servers are unaware of each other, but the client does the cooperation and knowledge sharing on their behalf.