Yes, good point as far as service interruption is concerned but I don't see how this affects performance, especially if the programmer carefully uses this feature for tiny amounts of data per user.... I just think, given how far memcache has metamorphosed, the time is probably right to include such a feature (to be used with some care of course)
On 10 March 2010 23:04, Dean Harding <dean.hard...@dload.com.au> wrote: > > My hunch is that the memcache devs have probably > > considered this idea but never went ahead with > > it..... I would be interested to know why? > > I'm not one of the devs, but I can guess why they wouldn't want to do this. > It's pretty simple: it's not just expiration and expulsion that can cause a > memcache node to lose keys. If you need to reboot a server, the data will > be > lost. If you have a hard disk crash and the server dies, you lose your > data. > > Of course, you can reboot database servers and so on as well, but they're > usually replicated so that there's no interruption of service and no data > lost. > > Besides, this feature could affect performance, and memcache is ALL about > performance. > > For us, our session data is usually mostly static. When you log on, we > create the session data and it doesn't change much until you log off. So we > actually store it in the database AND in memcache. The database then is > mostly write-only and only needed if a memcache node goes down and the key > is lost. > > Dean. > > >
