Mike McGrath wrote:
Matt Domsch wrote:
> 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 submits
>> 3) 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?
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
I'm tempted to say "because SQLObject sucks" but I'd have to do
analysis to know that SQLAlchemy wouldn't also suffer from this problem :-)
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
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.