Shared database domains
To maximize data availability, we can distribute portal data across multiple databases and for some domains, share data between multiple lines of production.
When you separate HCL WebSphere Portal data, we can store each category of data in its own set of database tables or the file system. 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, we can share domains across multiple portals. We can also spread the different domains across different database types. For example, we can choose to leave LikeMinds data on the 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. In WebSphere Application Server, the values of the portlet deployment descriptor are read-only. z/OS 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. Such a preference layer does not exist 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; 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 we use configure mode, you're working on the portlet definition level and the portlet preferences are stored on the release level. The following table lists the supported database domains, whether a domain is sharable, and notes.
Supported database domains:
Database domain Sharable Notes Release no In an environment that consists of multiple lines of production, one copy of the release data exists per cluster. Considered the domain as release data and promote to production lines individually. Customization yes 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 yes JCR no Considered the domain as release data and promote to production lines individually. Feedback yes LikeMinds yes Virtual Member Manager yes Sharing of database domains refers to concurrent access to the same physical database by multiple lines of production. A setup in which each line of production owns a copy of the shareable database domains and data replication is used to synchronize these copies is not supported. The following table summarizes the portlet modes, the database that data is in, and whether that database is sharable:
Portlet modes and where the data is stored...
Type Portlet mode Domain Shareable between multiple lines of production Administrator preferences config release no Shared preferences edit_defaults release no Personalized preferences edit customization yes For maintenance and staging purposes, we 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 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. We 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 HCL WebSphere Portal is started:
- Release
- JCR
While a database domain is offline, HCL WebSphere Portal cannot access the corresponding data and thus error messages might be displayed. HCL WebSphere Portal itself remains responsive. When a database domain becomes available again, HCL 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.
Configure portlet entity caches for multiple lines of production
We need to configure the portal cache settings, if we 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. Therefore, we must choose a cache lifetime, which balances your need for data coherence between lines of production and your need for portal performance. We can configure the lifetime of the corresponding portal caches com.hcl.wps.pe.portletentity and com.hcl.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.hcl.wps.pe.portletentity.lifetime=900
- cacheinstance.com.hcl.wps.pe.portletentitycounter.lifetime=900
This configuration defines a cache lifetime of 900 seconds. We 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 HCL WebSphere Portal Performance Tuning Guide.
Sharing of VMM databases
The Virtual Member Manager (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 we 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 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, HCL WebSphere Portal does not function.
Parent topic: Database
References: