Shared database domains



Search Tips   |   Advanced Search


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, Configuration, Release, Customization, Community, and IBM Java Content Repository (JCR). Separating your 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 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 same Community and Customization database domains, for example. Each of these clusters is called a line of production.

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

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 appserver administration rights.

Release data

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
  • 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.

Customization data

Associated with a particular user only and cannot be shared across users or user groups. Typical examples are Portlet Data or 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 all resources that are usually modified during production, such as shared documents or application resources. Typically, users and groups are allowed to modify or delete shared resources. Community resources are protected by access control. Because documents are a preferred class of shared resources supported with its own storage mechanism, this type of resource has the following subcategories:

Java Content Repository (JCR) data

Includes all the documents and IBM Lotus Web Content Management objects using this storage mechanism.

Application data

Includes all the other shared application data, which are not documents.

In an environment that consists of multiple lines of production, changes to data in the Community database domain are not reflected instantly across multiple clusters due to caching, since caches are not invalidated across clusters.

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

JCR domains and release domains cannot be shared between different Web Content Management clusters or servers. Each distinct cluster or server in your Web Content Management system must use a separate JCR or release domain.

For example:

Development Server Authoring Cluster Staging Server Delivery Cluster
JCR Domain 1 JCR Domain 2 JCR Domain 3 JCR Domain 4
Release Domain 1 Release Domain 2 Release Domain 3 Release Domain 4

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. When WebSphere Portal is being started all database domains must be accessible.

Consult the WebSphere Portal Performance Tuning Guide when scaling a system for optimum performance.

Share of VMM databases

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 topic: