On January 7, 2010, Guilherme Salgado wrote: > As I explained earlier, to make the read-only mode switching > transparent, I turned the main_master/slave config variables into > properties of DatabaseConfig, which return either rw_main_* or > ro_main_*, depending on the mode we're on. > > After our discussion we decided to cache the mode in the request so that > we only look for the file once for each request (and, more importantly, > it doesn't change mid-request). One small problem with that, though, is > that DatabaseConfig.main_master is called in some contexts which don't > have a request, so we need to cope with that. It doesn't sound like a > show-stopper to me, but I'd like to know what you think. >
What are those context? If there is no concurrent possibility, then it's not really an issue. > Here's the utility we discussed, which deals with a missing request > nicely: http://paste.ubuntu.com/353092/ > I wouldn't make the request part of the utility. I'd let the call site handle the request caching. The only responsibility of the utility is in monitoring and logging the read-only state change. -- Francis J. Lacoste [email protected]
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
