Shared database domains

Shared database domains

Overview

Database domains are used to distribute portal data across multiple databases, and share data between multiple lines of production. Database domain categories include: Configuration, Release, Customization, Community, and JCR.
We can transfer a single database domain or multiple domains. We can share domains across multiple portals. Different domains can be spread across different database types.
For example, we can leave LikeMinds data on the default database, and move all other data to another database. Or we can have each cluster run independently, but share the same Community and Customization database domains. Each of these clusters is called a line of production.
When a user customizes a portlet on a page in any standard mode, the user can change his portlet preferences. Portlet preferences are stored in the customization domain when stored by users using edit mode. Preferences are stored on the release level when using configure mode.

Domain categories

Configuration Portal server setup, such as database connection, object factories, and deployment descriptors. Typically kept in property files, not the DB. Protected by file system and application server security.
Release Content definitions, rules, and rights. available portlets and themes, templates, and credential slots. Typically created on an integration server and staged to production system. Protected by portal access control. Contains only data, not code. One copy per cluster.
JCR WCM content, Personalization rules and theme policy definitions.
Customization Associated with a particular user. Includes customized pages (Implicitly Derived Pages). In a system with multiple lines of production, typically kept in a shared database.
Community Resources modified during production. Typically, users and groups are allowed to modify or delete shared resources.

Supported database domains...

Database domain Sharable
Release no
Customization yes
Community yes
JCR no
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 imperativthat this data remain available to all lines of production currently in use.

Share of VMM databases

The Virtual Member Manager (VMM) databases map entries from multiple individual user repositories into a single virtual repository. The federated repository consists of a single named realm, which is has a set of independent user repositories.
Each repository may be an entire external repository or, in the case of LDAP, a subtree withis 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 considerations

Configuration	Portal server setup, such as database connection, object factories, and deployment descriptors. Typically kept in property files, not the DB. Protected by file system and application server security.
Release	Content definitions, rules, and rights. available portlets and themes, templates, and credential slots. Typically created on an integration server and staged to production system. Protected by portal access control. Contains only data, not code. One copy per cluster.
JCR	WCM content, Personalization rules and theme policy definitions.
Customization	Associated with a particular user. Includes customized pages (Implicitly Derived Pages). In a system with multiple lines of production, typically kept in a shared database.
Community	Resources modified during production. Typically, users and groups are allowed to modify or delete shared resources.