Shared database domains


Overview

Database domains classify and help you determine how to distribute portal data. To maximize data availability, you can distribute portal data across multiple databases and, for some domains, share data between multiple lines of production. You can choose to transfer a single database domain or multiple domains.

Separation of data allows you to store each category of data in its own set of database tables or the file system. The sets of databases tables and schemas for portal resources are called database domains. Database domains support the storage and transfer of data by category, for example...

Separating data allows you to share domains across multiple portals. You can also spread the different domains across different database types. For example, you can choose to leave LikeMinds data on default database and move all other data to another database. The separation of the domains can be used to support production environments, where the production nodes are split into separate clusters. Each cluster can run independently, but share the same Community and Customization database domains, for example. Each of these clusters is called a line of production.

Preferences are kept in layers that are modifiable based on portlet modes. For example, there is one layer of default preferences defined by the portlet deployment descriptor. This layer is modifiable within the CONFIG mode supported by WebSphere Portal. In WAS, the values of the portlet deployment descriptor are read-only. WebSphere Portal provides one additional preference layer that enables portal administrators to specify different default values per portlet window. This capability is supported through the portlet mode EDIT_DEFAULTS, and applies to all who use the same portlet window. There is no such preference layer in WAS. Both products support the standard modes: VIEW, EDIT, and HELP. When a user customizes a portlet on a page in any standard mode, the user can change his personal portlet preferences. Default preferences on a per page or per portlet base cannot be set in any standard mode; you need to use custom portlet modes instead. Porltet preferences are stored in the customization domain when stored by users (typically in edit mode) on the entity level whereas when using configure mode, we're working on the portlet definition level and those are stored on the release level.

The database domains categorize portal data into the following categories and subcategories to help you decide how to distribute portal data into different databases:

Configuration data Defines the portal server setup, such as database connection, object factories, and deployment descriptors. This type of data typically is constant during the time a server node is running. Configuration data is typically kept in property files and is either protected by file system security or application server administration rights.
Release data Includes portal content definitions, rules, and rights that are designed externally then brought into the portal by a staging process, such as Page Hierarchy, available Portlets and Themes, Templates, Credential Slots, Personalization Rules, and Policies. These resources are typically not modified during production and need administrative rights to do so. Administrators typically create release data on an integration server and stage it to the production system. Release data are protected by access control and contain only data, not code. In an environment that consists of multiple lines of production, one copy of the release data exists per cluster. Release data includes the following two separate domains:

  • Release: Contains portal's static site configuration, including access control, pages, and portlets.

  • JCR: Contains authored content, Personalization rules, and theme policy definitions.

These should be considered release data and promoted to production lines individually.
Customization data Associated with a particular user. Cannot be shared across users or user groups. Typical examples are Portlet Data or Customized Pages (Implicitly Derived Pages). Because this data is scoped to a single user only, access control protection is simplified.

In an environment that consists of multiple lines of production, customization data is kept in a database that is shared across the lines of production. Therefore the data is automatically in synchronization across the lines of production.

Community data Includes resources modified during production, such as Composite Application instances. Typically, users and groups are allowed to modify or delete shared resources. Community resources are protected by access control.

The following table lists the supported database domains, whether a domain is sharable, and its storage method.

Database domain Sharable Storage method
Release no database
Customization yes database
Community yes database
JCR no database
Feedback yes database
LikeMinds yes database

For maintenance and staging purposes you can take a single line of production out of service while another line is still serving requests with the old data. After the first production line is updated and back in service again, the second line is updated using the same approach. Updates of data in the shared domain are critical because they influence the other production line.

The capacity of the entire environment should be greater than the intended use so that individual servers can be taken out of production without affecting application availability. To ensure that all of the system resources are available for the portal, production systems should be dedicated to the portal and should not run any other server software that is not related to the portal.

For maintenance purposes, the following database domains can be taken offline:

The following databases must not be taken offline at anytime when WebSphere Portal is started:

While a database domain is offline, WebSphere Portal cannot access the corresponding data and thus error messages may be displayed. WebSphere Portal itself remains responsive. When a database domain becomes available again, WebSphere Portal will detect this availability, reconnect, and continue working with the corresponding data. Regular maintenance should not affect the shared database domains because it is imperative that this data remain available to all lines of production currently in use.


Share of VMM databases

The VMM database feature makes it much simpler to use multiple repositories, since this capability is achieved through configuration, rather than development, with the use of the new VMM. In essence, this feature provides the ability to map entries from multiple individual user repositories into a single virtual repository. The federated repository consists of a single named realm, which is a set of independent user repositories. Each repository may be an entire external repository or, in the case of LDAP, a subtree within that repository. The root of each repository is mapped to a base entry within the federated repository, which is a starting point within the hierarchical namespace of the virtual realm.The Virtual Member Manager (VMM) databases for a full repository and for the property extension can be shared between lines of production. If the VMM databases are out of service, WebSphere Portal will not function.


Parent

Database considerations

 


+

Search Tips   |   Advanced Search