nice (repcache and memcachedb work well...) is the lock daemon generic? (not filesystem based)
2011/1/29 Dustin <dsalli...@gmail.com>: > > 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. -- Roberto Spadim Spadim Technology / SPAEmpresarial
