I know I can do all of that, and I understand that is the typical method. I'm just looking one step further. It's not that I want to lose the updates if they bail between timeouts. I'd rather not. So I'm stuck see, writing every microscopic change to the db, unless I compose a transaction of changes I want to make, and then commit that every few minutes (or whatever).
Just thought it would be nifty to have memcached return values it was going to expire, or delete, and write them out to db when I get them. Just thinking. :-) On Dec 5, 7:01 am, "Henrik Schröder" <[EMAIL PROTECTED]> wrote: > On Fri, Dec 5, 2008 at 00:32, Justin Mecham <[EMAIL PROTECTED]> wrote: > > > I'm guessing several thousand calls for the player object per minute, > > at a minimum. And if each of those creates a write operation, it seems > > to me that'd be a big batch of avoidable disk paging. > > Every time you access the player object, you get it from the cache, which is > fine. > > Every time you update the object, you should typically first update the > cached object, then write the changes to the DB. > > If you have lots of small updates and you can stand to lose some of them, > you can put a timestamp on the cached object that tells you when you last > wrote changes to the DB. That way, every time you do a small update you > check the timestamp, if it's less than whatever threshold you choose, you > just update the cached object, but if it's larger, you update the timestamp > as well, and write the changes to disk. > > /Henrik
