tag:blogger.com,1999:blog-23714519.post4373551734348680218..comments2023-10-18T02:14:08.061+11:00Comments on Alex's Corner: Is framework-level SQL query caching dangerous?kuza55http://www.blogger.com/profile/03932544559060480887noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-23714519.post-81487692038775536552008-08-30T12:23:00.000+10:002008-08-30T12:23:00.000+10:00Nice thoughts Kuzz55. Definitely research worthy.O...Nice thoughts Kuzz55. Definitely research worthy.<BR/><BR/>Overall, I never liked caching at any level including not not limited to browsers. But you're right a race condition seems plausible right there. It's who owns the most connections will win the cache. Said that, even a small cache TTL will not save them if you own the most connections racing against someone else. Caching queries or requests is bound to fail.<BR/><BR/>/rvdhAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-23714519.post-2533636453474768992008-08-04T10:48:00.000+10:002008-08-04T10:48:00.000+10:00I agree that framework level SQL query caching is ...I agree that framework level SQL query caching is dangerous, but only because I was personally bitten by it by another framework (CakePHP). The danger lies in two things, I think:<BR/><BR/>1. External access to the database, as you mention. This doesn't have to be another application; it can be introspective SQL that doesn't map from one input to one output (random functions, time functions , etc).<BR/><BR/>2. Reliance on the cache being "perfect". If a query cache is implemented by default, it is probably meant to be completely transparent, and when the cache handles something it shouldn't handle, you get a mysterious bug unless you know about the query cache.<BR/><BR/>When the data isn't that important, query caches can be a useful way of quickly improving the performance of SQL-inefficient code. The correct way to fix this, however, is transactional support and caching implemented on a database mapper level.Ambush Commanderhttps://www.blogger.com/profile/08963503454239819127noreply@blogger.com