launchpad-dev team mailing list archive

[Guilherme Salgado <salgado@xxxxxxxxxxxxx>]

On Thu, 2010-01-07 at 15:43 -0500, Francis J. Lacoste wrote:
> 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.

Scripts.  ZopelessTransactionManager and sqlbase.connect (which is
deprecated and only used in scripts).  Another option would be to change
them to use rw_main_master directly, since that's what they need.

> 
> > 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.
> 

We'll have a bunch of callsites for the utility
(DatabaseConfig.main_master/slave, model/pofile.py, webapp/adapter.py,
webapp/authorization.py, webapp/dbpolicy.py, and others), and nearly all
of them would benefit from a cache in the request, so I'd rather do it
in the utility.

-- 
Guilherme Salgado <salgado@xxxxxxxxxxxxx>

Attachment: signature.asc
Description: This is a digitally signed message part