there are some excellent solutions out there already. check out, for example, zookeeper.
awl On Jan 29, 2011 3:32 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/ > ================================================================================= > 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/ > > ================================================================================= > 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? > > what lock manager do? > client send: KEY NAME, lock type+client name (KEY VALUE), key timeout, > wait lock timeout (infinity/seconds) > (this can be implement in memcached protocol without many > modifications!!!) > server side function: > 1)seek if client can have this lock > 2)wait lock timeout... (this is a problem since we can have a very big > wait time...) > 3) if client disconect exit do while > 4) yes we have the lock => change key value (give this lock to > client), exit do > 5) no we don't have the lock, exit do > 6) end of do while... return key value: lock type + client name (like > a get command) > > ideas: > 1)maybe a separated memory size? we can run two separated servers, one > for keys another for lock function (make command line options: just > lock system, objects only system or both) > > 2)this type of key is diferent from memcached key cache objects, > that's obvious > > but........ is managed with same functions... (get, list, etc) > but........ > all write/delete functions can't be done, they MUST be done by LOCK > (the new) function, > DELETE/UNLOCK function is a LOCK function with lock type=0 (unlock) > read can be done by get and will return current client lock name and > lock type (get command) > > > > *WHY THIS FEATURE?* > i didn't found a distributed lock manager for user space (not kernel > space) with easy to implement protocol, and many program languages, > and a very mature server and protocol. > =( > > but with this feature... > I DON'T NEED A SAMBA/NFS SERVER FOR NON FILESYSTEM LOCKING!!!!! \o/ > I WILL NEVER USE FLOCK() AGAIN!!! \o/ !!! > > I JUST NEED: > MYSQL+MEMCACHED+ (APACHE+CGI/PHP/JAVA/PERL/PYTHON) > for any cluster solution, no more filesystem!!! > > NO MORE FILESYSTEM REPLICATIONS (DRBD, NBD+RAID) FOR MY HIGH > AVAIBILITY / CLUSTER SOLUTION!!!!! > WE CAN USE REPCACHED (WE NEED A SYNC MODE).... > > THINK ABOUT IT!!! > REPLICATION + FLOCK!!!!! IT'S A VERY VERY VERY NICE FEATURE!!!!! > > ==================== > type of object (1bit) default / lock manager can be putted on key > options/flags!!! > inside key value, we can put: > lock type(3 bits) > client name (a variable length, many bytes) > > http://en.wikipedia.org/wiki/Distributed_lock_manager > from wikipedia, TYPE OF LOCKS: > * Null Lock (NL). Indicates interest in the resource, but does not > prevent other processes from locking it. It has the advantage that the > resource and its lock value block are preserved, even when no > processes are locking it. > * Concurrent Read (CR). Indicates a desire to read (but not > update) the resource. It allows other processes to read or update the > resource, but prevents others from having exclusive access to it. This > is usually employed on high-level resources, in order that more > restrictive locks can be obtained on subordinate resources. > * Concurrent Write (CW). Indicates a desire to read and update the > resource. It also allows other processes to read or update the > resource, but prevents others from having exclusive access to it. This > is also usually employed on high-level resources, in order that more > restrictive locks can be obtained on subordinate resources. > * Protected Read (PR). This is the traditional share lock, which > indicates a desire to read the resource but prevents other from > updating it. Others can however also read the resource. > * Protected Write (PW). This is the traditional update lock, which > indicates a desire to read and update the resource and prevents others > from updating it. Others with Concurrent Read access can however read > the resource. > * Exclusive (EX). This is the traditional exclusive lock which > allows read and update access to the resource, and prevents others > from having any access to it. > > NEW LOCK FUNCTION: > > LOCK <key><lock_type><client name><timeout><wait lock timeout> > > key: key name > <lock_type+client_name>=key value > > lock_type: > NL = 0 > CR = 1 > CW = 2 > PR = 3 > PW = 4 > EX = 5 > > client name: any value > timeout: any number, 0=infinity > wait lock timeout: wait lock time, 0=infinity > > how lock works: (see that lock type is only 0 or !=0 in this logic...) > i will use <sent xxxx> for user new value, and <current xxx> for the > current server value > > if key don't exists, create > do{ > if ((sent_lock_type = 0 and sent_client_name = current_client_name) > or key_timed_out==1) > remove key (delete) > send null lock and sent_client_name information > exit function > }else if (sent lock type = (1 or 2 or 3 or 4 or 5), and current user > = sent user) > set > current_client_name,current_lock_type=sent_client_name,sent_lock_type > exit do > }else{ > if wait lock time < time waiting lock to occur > exit do > } > }while(1) > send current_lock_type and sent_client_name > exit function > > > thanks guys!!!
