← Back to team overview

launchpad-dev team mailing list archive

Re: Using a signal to switch to read-only mode

 

On January 11, 2010, Guilherme Salgado wrote:
> On Mon, 2010-01-11 at 15:32 -0500, Gary Poster wrote:
> > On Jan 11, 2010, at 2:59 PM, Guilherme Salgado wrote:
> > > 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?
> >
> > Can we check to explicitly close connections at the end of a request?
> 
> (Just discussed this with Gary on IRC and...)
> Ok, so the plan now is to, at the end of a request (or maybe at the
> beginning?), compare the databases of all our connections against
> dbconfig.main_master and if they differ we close them, forcing a reopen
> which will then connect to the correct db.
> 

Sounds good. I'd do it at the start. That seems also related to the problem 
with the DisconnectionError we are seeing because of the stuck storm state.


-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

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


Follow ups

References