Portal, V6.1
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
Separation of portal 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
- Java Content Repository
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 JCR and Customization database domains, for example. Each of these clusters is called a line of production.
You can transfer data from one supported database type to another 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.
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, including...
- database connection
- object factories
- 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 application server administration rights.
- Release data
- Includes...
- Portal content definitions
- Rules
- Rights 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...
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
- 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 subcategories:
- JCR data
- Includes all the documents 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.
Supported database domains
Database domain Sharable Storage method Configuration no file system Release no database Customization yes database Community no database JCR sharable if WCM is not installed database Feedback no database LikeMinds no database The Java Content Repository (JCR) supports domain sharing across lines of production. While all lines of production have access to all data in the JCR domain, the segregation of data must be explicitly managed in the portal environment and by applications because the JCR does not provide inherent segregation between lines of production.
Limiting access to JCR data is achieved by...
Lines of production that share a JCR domain must use the same database schema level. Because the JCR data resides in the same database, any JCR changes applied to the domain will affect all lines of production. In a future release of the product, checks will be implemented to detect and verify the correct level of the JCR database schema. These checks will preclude different lines of production running differing JCR code bases that require different schema levels in a shared domain.
If you are using WCM servers in your environment, you cannot share the JCR domain between servers.
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.
Parent topic
Planning for databases