Hi, it is primitive implementation. Many threads can repeats one job. The best solution is acquiring the mutex, if acquired than we have to do the job and write to memcached, else we have to wait untill another thread (who acquired) does the job.
On 25 мар, 12:32, Toru Maesaka <[email protected]> wrote: > Hi! > > This is not what memcached should do. > > If a particular item doesn't exist, the daemon should not have to do > anything extra. If you get a miss, it's a miss. This is a golden rule > that should not be complicated nor broken. > > If you want to populate the missing item, do it after you get a miss > from memcached in the application layer by read-through caching... > this is how memcached is intended to be used. > > Cheers, > Toru > > On Sun, Mar 22, 2009 at 8:20 PM, gf <[email protected]> wrote: > > > Hello. It would be great to add new "wait timeout" argument to the get > > () method. If it is defined and the key doesn't exists a the moment, > > client should wait untill the key will be added or untill the timeout > > will be reached (client gets false in this case) and get feedback as > > soon as possible. > > It can be used at many cases. > > For example, I shall use it to improve my IMemcacheClient (http:// > > code.google.com/p/imemcacheclient-php/) in the following aspects: > > 1. Improving acquire() method, it will have no necessary to repeat > > acquire() tries. > > 2. In my distributed queues system, getNext() will have no necessary > > to repeat get() tries when it's waiting for new messages. > > > Internally, I think it necessary to create a hash of connections > > waiting for the key (key -> clients), and hook the set() and add() > > methods to send value _after_ the operation and asynchronous to > > original client calling set() or add() method. > > > Thank you.
