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. We can choose to transfer a single database domain or multiple domains.
Separation of WebSphere Portal data allows us to 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). Separating your data allows us to 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 same Community and Customization database domains, for example. Each of these clusters is called a line of production.
Preferences are kept in layers 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 WebSphere Application Server, 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 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 his personal portlet preferences. Default preferences on a per page or per portlet base cannot be set in any standard mode; we 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. When using configure mode, we are working on the portlet definition level, and those preferences are stored on the release level.
The following table lists the supported database domains, whether a domain is sharable, and notes.
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. Customization yes In an environment that consists of multiple lines of production, customization data is kept in a database 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 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 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:
- 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 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 VMM databases
The Virtual Member Manager (VMM) database feature uses multiple repositories, achieved through configuration rather than development. VMM 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 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