On Wed, Jan 6, 2010 at 8:20 PM, Guilherme Salgado <[email protected]> wrote:
> After realizing that I came up with another approach, which relies only > on the presence/absence of the read-only.txt file to figure out the mode > we're on. On this approach, config.database.main_master/slave are gone > and we use dbconfig.main_master/slave instead, which are properties in > DatabaseConfig that return the appropriate value according to the mode > we're on. Does this mean we're checking for the presence of this text file before every database operation? That sounds quite IO intensive.ISTM that the presence of the file would be checked only a couple times (once for each of the properties in DatabaseConfig that look for that file) for each handler thread, as a consequence of storm creating the DB connections when they're first used. If that's correct, then we'll have to find a way to reset the stores in all threads when we switch modes -- something I didn't realize before.
You can look for this file at the start of the request when installing the database policy and change the database settings for just the current thread. That is just one stat() per request rather than per database operation. We certainly wouldn't want the appserver to be changing from normal to read-only mode half way through handling a request. -- Stuart Bishop <[email protected]> http://www.stuartbishop.net/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
