Mike McGrath wrote:
I'm tempted to say "because SQLObject sucks" but I'd have to do more analysis to know that SQLAlchemy wouldn't also suffer from this problem :-)Matt Domsch wrote:I've tried stuff like that in the past, its sub-optimal and hacky :) Why are we even using cache for MM? Its pretty low traffic compared to the mirrorlist.On Fri, Nov 02, 2007 at 09:06:04PM -0700, Toshio Kuratomi wrote:1) app3 serves the site form. 2) User fills out form and submits3) app4 processes the form results (including the call to site.sync()) and raises a redirect back to the form. 4) app3 gets the request and pulls the stale data out of its cache because site.sync() wasn't called on this server.Another option that dawns on me, that also matches Mike's goals for the applications servers, would be to change the balancer. Instead of evenly balancing between app3 and app4, we set the weight on app3 to be very very high, like 2^32-1 or whatever the max is, and set the weight for app4 to be 1. That will redirect the traffic to app3 all the time, except when it's offline, in which case it'll redirect to app4, yes?
Basically, SQLObject without caching enabled makes a fresh call to the database for every access of an object which is persisted in the database. Iterate through a list of records more than once (once to convert a value to unicode, the second to output a menu, the third to output the record itself,... etc) and you hit the database innumerable times.
SQLObject with caching is more efficient. From what I've seen, SQLAlchemy is even more efficient than that. I think SQLAlchemy is also designed to be immune to this stale cache problem but I'd want to test it to make sure. The PackageDB tries to avoid making redirect calls so it might be different design decisions in the apps rather than SO/SA differences that allow it to avoid this problem.