Configuration and sessions
Ensembl has two different types of configuration: system and user.
System settings are controlled by the administrator of Ensembl.
Apache web server configuration
SiteDefs.pm Perl module holds the information required to build the
httpd.conf file to configure Apache (i.e. port number, modules etc). Some knowledge of Perl is required to edit and maintain this file.
A SiteDefs object is instantiated by the parent Apache process, and is made available to all scripts served by a child process. The role of Apache in serving pages is discussed in Apache Loop.
Site configuration and species definitions
A series of
.ini files are used to specify virtually every other configurable section of Ensembl. These are easier to configure than a perl module and are only needed by the child processes. The
MULTI.ini files contains a set of default settings for all species, but each species appearing in Ensembl can augment or overwrite these settings with its own
.ini file. All these files are located and parsed at server startup by
Configuration options specified in the
.ini files include (but are in no way limited to):
- Default database connection settings
- Homology search settings
- Paths to utilities used by the site
- Parameters that control the look and feel of the site
Accessing system configurations
As the information from
SiteDefs.pm is pulled into
SpeciesDefs.pm, all these settings (be they server, site or species) are accessible from the global package
SpeciesDefs. No instantiation should be necessary to access the settings as the SpeciesDefs object is instantiated early by
EnsEMBL::Web::Page and then passed around.
Seperate from the actual system configuration, it is often helpful to store additional configuration information on a per user basis. For example, should a user elect to hide a number of tracks, it makes for a better user experience if Ensembl remembers those changes for subsequent visits to the site. Ensembl does this based on user sessions.
Any time a user makes a configuration change to a view in Ensembl, a new user session is started. This links a particular browser to a particular Ensembl configuration, by storing a cookie containing a unique identification number in the browser.
The cookies are only created when needed, by
EnsEMBL::Document::WebPage. They store an encrypted
version of the session ID from the
%ENV variable (instantiated by the Post Read Request handler).
When a new session is started, a new entry is made in the optional WebUser database and all configuration changes are stored against it. This ensures that configuration changes are persistant per session.
Accessing user configurations
Two modules are used to maintain state in this way:
ScriptConfig. Both use the same WebUser database for storing and trieving information, and both check and create session identifiers if necessary.
UserConfigis used to store information about a particular view's images. For example, which tracks are active.
ScriptConfigstores options for a particular script or page. For example, the width of the page, which panels are visible and which are collapsed.
Instead of saving all configuration options in the databse, these configuration modules actually store the difference from the default settings. With this implementation new default options will not be overridden by older session information.
Footnotes on ensembl_accounts
UserConfigreads the session ID from the cookie and then looks up the session data in the ensembl web user database (ensembl_accounts). If this database goes down, session data requests back up and eventually the whole site does down.
- Data is not deleted from the ensembl_accounts database.
- The user logins system uses the same database but different tables.