If instead of a select you do a select for update I think this would be transaction safe. Nothing would be able to modify the data in the database between when you do the SELECT and when you commit. If the transaction fails the value in memcached will be correct. Also, it's not clear if you're doing an update here or not... If you're doing an update then this wouldn't work. You'd want to do your update, then re-insert the value into memcached outside of the update transaction. On Tue, Nov 23, 2004 at 02:20:34PM -0800, Sean Chittenden wrote: > >My point was that there are two failure cases --- one where the cache > >is > >slightly out of date compared to the db server --- these are cases > >where > >the cache update is slightly before/after the commit. > > I was thinking about this and ways to minimize this even further. Have > memcache clients add data and have a policy to have the database only > delete data. This sets the database up as the bottleneck again, but > then you have a degree of transactionality that couldn't be previously > achieved with the database issuing replace commands. For example: > > 1) client checks the cache for data and gets a cache lookup failure > 2) client beings transaction > 3) client SELECTs data from the database > 4) client adds the key to the cache > 5) client commits transaction > > This assumes that the client won't rollback or have a transaction > failure. Again, in 50M transactions, I doubt one of them would fail > (sure, it's possible, but that's a symptom of bigger problems: > memcached isn't an RDBMS). > > The update case being: > > 1) client begins transaction > 2) client updates data > 3) database deletes record from memcache > 4) client commits transaction > 5) client adds data to memcache > > >The second is > >where the cache update happens and the commit later fails, or the > >commit > >happens and the cache update never happens. > > Having pgmemcache delete, not replace data addresses this second issue. > -sc > > -- > Sean Chittenden > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your > message can get through to the mailing list cleanly > -- Jim C. Nasby, Database Consultant decibel@xxxxxxxxxxx Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
