i don't see any question to say: it's not a good feature to be implemented just one thing: my scenario isn't your scenario, i need only one server, cache timeout isn't a problem, no value in cache isn't a problem, i just need a simple lock / unlock function, i will make all app relative operations at app(client) side a lock unlock can be done in client side, but my client is very slow, at server we can make it faster (no problem if cache expires) you can retrieve key-value with get, and you can use lock/unlock with any key-value entry for example
set key=10 get key set key=40 lock key=50 lock key=40 unlock key=40 delete key any of this functions could work, lock return the key value if exists, error if can't return key value or can't add the key if it not exists unlock delete key only if sent value = server side value, unlock return the deleted key value if deleted, or current key if not deleted easy? with it i can have 3 or more send/receive removed from my pic18f4550 code (save a lot of rom for me) 2011/2/4 Les Mikesell <lesmikes...@gmail.com>: > On 2/4/2011 9:34 AM, Roberto Spadim wrote: >> >>>> What happens when the server holding the lock value is rebooted? Or >>>> needs to evict values from memory? For memcache's real>purpose those >>>> things >>>> don't affect operation because the client will reload the correct values on >>>> the next access. Where is the>persistent backing store for this value? >> >> if elockd/lockd/any other lock server die, what happen? (non vollatile >> or vollatile? it's a app problem not memcache problem, app must know >> what happen, just it. > > If they are designed to be reliable, the value will be stored redundantly > and the system will know how to retrieve the copy that is still valid or an > error if that is impossible. It is an application problem. It is not an > error if a cache cannot return data. For a lock you must have the correct > value or an error condition. And it doesn't make sense to have the memcache > server check for the difference on every request when the client could just > call an application designed for the more complex operation you need when it > knows it needs a lock. > >> with memcache we have volllatile, with memcachedb we have non >> vollatile, put at main memcache and i will work with memcachedb and >> repcache to sync this new feature at others memcache forks > > It probably can be done with membase. I don't think memcachedb is intended > to be reliable. > >> who will use memcache for lock and don't want loose keys change >> memcache command line to don't delete cache keys if cache is full >> non volatille? > > That still doesn't work in the usual scenario where you have many memcache > servers and expect them to keep working even if some are down. > >>>> timeout could work too (it's key-value based) >>> >>> Memcache is a cache, not a key-value store. >> >> nice, it's a cache (can loose information) it's a key-value store with >> timeout and volatille data, right? define cache! (volatile memory? how >> to cache? based on key-value? based on memory address? it's a >> key-value store! working as a cache! it could be a address-value store >> too, but it's a key-value store... and can loose information, app must >> know this!) > > A cache must have a method where the correct value can be retrieved when it > is empty. How can either the clients or server replenish the value of the > lock when it is gone for any reason? > >> i use memcache for store some values with pic18f4550 and it's very >> good, since my pic have low memory and my server have a lot of memory > > Yes, it is very good for holding values for quick access that you are able > to retrieve in some slower way. > > -- > Les Mikesell > lesmikes...@gmail.com > -- Roberto Spadim Spadim Technology / SPAEmpresarial
