launchpad-dev team mailing list archive

[Gavin Panella <gavin.panella@xxxxxxxxxxxxx>]

On Wed, 06 Jan 2010 10:22:09 +0000
Tom Haddon <tom.haddon@xxxxxxxxxxxxx> wrote:

> On Wed, 2010-01-06 at 10:46 +0700, Stuart Bishop wrote:
> > On Wed, Jan 6, 2010 at 10:30 AM, Martin Pool <mbp@xxxxxxxxxxxxx> wrote:
> > 
> > > Perhaps a similar method could be used in future for site-wide
> > > notifications.  <https://dev.launchpad.net/NotificationSystem>.  For
> > > example if there is a site-wide-notification.txt, it can contain
> > > configuration for a message to be displayed in a banner at the top of
> > > some or all html pages.
> > 
> > I'd rather pull this information from the database or even ajax load
> > it from a static URL. Coordinating the .txt files over all the
> > different appserver trees is a pain we should avoid when possible.
> 
> Er, which database? Wouldn't that make the whole "read-only" thing a
> little more problematic (i.e. how do you switch out of read-only when
> you're checking a DB that's not writable)?
> 

If the DB is not writable, I think you shouldn't be switching out of
read-only mode on the app servers. That sounds like it will break.

How about the following approach, instead of read-only.txt files?

 * For each request, check for a flag/setting in the db that says
   read-only. This means we can put the DB in a soft read-only state,
   where existing requests can complete, but new requests will be
   read-only.

 * At some point after the soft flag has been set, switch the DB to
   its "proper" read-only state.

 * For each request, also check if the DB is "proper" read-only, in
   case the soft flag was not set for any reason.