Part of lp.services.database.interfaces View In Hierarchy
Stores come in two flavors - MASTER_FLAVOR and SLAVE_FLAVOR.
The master is writable and up to date, but we should not use it whenever possible because there is only one master and we don't want it to be overloaded.
The slave is read only replica of the master and may lag behind the master. For many purposes such as serving unauthenticated web requests and generating reports this is fine. We can also have as many slave databases as we are prepared to pay for, so they will perform better because they are less loaded.
Method | push | Install an IDatabasePolicy as the default for this thread. |
Method | pop | Uninstall the most recently pushed IDatabasePolicy from |
Method | get_current | Return the currently installed IDatabasePolicy . |
Method | get | Retrieve a Storm Store. |
IDatabasePolicy
from
this thread.
Returns the IDatabasePolicy
removed.
Results should not be shared between threads, as which store is returned for a given name or flavor can depend on thread state (eg. the HTTP request currently being handled).
If a SLAVE_FLAVOR is requested, the MASTER_FLAVOR may be returned anyway.
The DEFAULT_FLAVOR flavor may return either a master or slave depending on process state. Application code using the DEFAULT_FLAVOR flavor should assume they have a MASTER and that a higher level will catch the exception raised if an attempt is made to write changes to a read only store. DEFAULT_FLAVOR exists for backwards compatibility, and new code should explicitly state if they want a master or a slave.
Raises | MasterUnavailable | |
DisallowedStore |