launchpad-dev team mailing list archive

[Guilherme Salgado <salgado@xxxxxxxxxxxxx>]

On Fri, 2010-01-08 at 09:27 -0200, Guilherme Salgado wrote:
> 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.

When I came up with the plan above I think I blindly assumed the next
time a request kicked in after a mode switch, it would re-connect to the
database, thus connecting to the appropriate one. That doesn't happen;
the connections to the database will be reused (and thus stay connected
to the DB that was appropriate when they were created) until they are
explicitly closed or left marked as dead.

I can't think of an easy way to close a connection at the beginning of a
request (as we don't want to switch modes mid-request) and only once for
each connection. Do you guys have any ideas?

I'm starting to think it'd be better to have the switch require the
read-only.txt file be put in place plus the server restarted, and then
later we can work on making it work without a restart. But I wonder if
just replacing the config changes (currently needed to switch) with the
read-only.txt file is a significant win to the LOSAs?

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