Shared database domains

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.

When you separate WebSphere® Portal data, you can 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, Configuration, Release, Customization, Community, and IBM® Java Content Repository (JCR). When you separate your data, you can 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 your 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 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, you can find one layer of default preferences that are defined by the portlet deployment descriptor. This layer is modifiable within the CONFIG mode that is supported by WebSphere Portal. In WebSphere Application Server, the values of the portlet deployment descriptor are read-only. WebSphere Portal provides one more 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 WebSphere Application Server. 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 their 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. Portlet preferences are stored in the customization domain when stored by users (typically in edit mode) on the entity level. Whereas, when you use configure mode, you're working on the portlet definition level and the portlet preferences are stored on the release level.

z/OS® only: You can transfer data from any supported database type to any supported database type, with the following exceptions:

Data cannot be transferred to an Apache Derby database.
Data cannot be transferred from an IBM DB2 Universal Database™ for z/OS database.

z/OS only: The only two supported database management systems for WebSphere Portal are Derby and DB2® for z/OS. Therefore, you can transfer data only from Derby to DB2 for z/OS.

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

This data defines the portal server setup, such as database connection, object factories, and deployment descriptors. This type of data is constant during the run time of a server node. Configuration data is typically kept in property files and is either protected by file system security or application server administration rights.

Release data

This data includes all 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 is protected by access control and contains 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 static site configuration, including access control, pages, and portlets.
JCR: Contains authored content, Personalization rules, and theme policy definitions.

These domains must be considered release data and promoted to production lines individually.

Customization data

This data is associated with a particular user only and 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

This data includes all resources that are modified during production. 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.

Table 1. Supported database domains
Database domain	Sharable	Storage method
Release	no	database
Customization	yes	database
Community	yes	database
JCR	no	database
Feedback	yes	database
LikeMinds	yes	database

The following table summarizes the portlet modes, the database that data is in, and whether that database is sharable:

Table 2. Portlet modes and where the data is stored
Type	Portlet mode	Domain	Shareable between multiple lines of production
Administrator preferences	config	release community	no
Shared preferences	edit_defaults	release community	no
Personalized preferences	edit	customization	yes

Note: Some custom applications and specialized uses of Portal might store data in the community domain with the config or edit_default modes. The data is shareable across multiple lines of production. Contact IBM Support if clarification is needed for which domain data is stored in.

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 by 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 must 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 must be dedicated to the portal. You must not run any other server software that is not related to the portal.

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

Community
Customization
Feedback
LikeMinds

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

Release
JCR

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

Configuring portlet entity caches for multiple lines of production

You need to configure the portal cache settings, if you plan to use multiple lines of production and if portal users customize portlets to change their personal portlet preferences. Since portal caches portlet entities, if the cache is not refreshed portal preference changes created on a first line of production are not visible on the second line of production. It is important to cache the most relevant portlet entities. Disabling these caches degrade portal performance. You must therefore choose a cache lifetime, which balances your need for data coherence between lines of production and your need for portal performance. You can configure the lifetime of the corresponding portal caches com.ibm.wps.pe.portletentity and com.ibm.wps.pe.portletentitycounter. Both caches are accessed many times during portal request processing.

To define the cache lifetime, configure the following properties in the CacheManagerService. For more information, see Cache Manager Service.

cacheinstance.com.ibm.wps.pe.portletentity.lifetime=900
cacheinstance.com.ibm.wps.pe.portletentitycounter.lifetime=900

This configuration defines a cache lifetime of 900 seconds. You can choose another lifetime if required. The cache lifetime must be at least 5 to allow portlet entities to be cached for one request. For more information about caches, see WebSphere Portal Performance Tuning Guide.

Sharing 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, with this feature you can 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 might 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 does not function.