wiki madness

[Toshio Kuratomi]

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 
> the mirrorlist.
> 
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 :-)

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.

-Toshio