Oracle WebCenter State Replication Understanding the Distributed Java Object Cache

6-40 Oracle Fusion Middleware High Availability Guide

6.3.2.4 Oracle WebCenter Analytics Communications

Oracle WebCenter Analytics consists of individual Collectors which receive requests from Oracle WebCenter Analytics clients, such as Oracle WebCenter Spaces. This section describes how an Oracle Analytics Collector cluster works. In a clustered environment, producers clients of the collector and collectors are configured with a cluster-specific channel name. Each collector periodically broadcasts a heartbeat with its location to the cluster-specific channel. The producer listens to the channel for these collector heartbeats, and when it hears one, adds the collector to its list of known collectors. When the producer needs to send an event, it uses a round robin algorithm to select a collector from its list and sends the event to that collector. If a collector stops either being stopped purposefully or failing, it stops broadcasting a heartbeat. When the producer stops hearing the heartbeat it removes the collector from its list and stops sending events to that collector. If the producer does not hear any collector heartbeats, it does not send any events. Oracle WebCenter Analytics uses UDP and multicast on a configured set of ports to communicate with its clients. For a single node setup, the client is configured with a WLST command that has the server hostport location and simply transmits all events to this location via UDP. For a multiple node setup, the server is configured to broadcast via UDP multicast the locations of the various servers running on the cluster; the client is configured with the same WLST command, so it will receive the locations of these servers and keep the list of available servers in a list which is persisted in memory. Additionally, if a client does not receive a periodic heartbeat from a server to indicate it is functioning, it will remove that server from its list of known servers, and will cease sending events to it. Oracle recommends that Collectors be configured as unicast, forming a 1-1 relationship with the Oracle WebCenter Analytics client.

6.3.2.5 Oracle WebCenter State Replication

Oracle WebCenter relies on Oracle ADF, which has several stateful components. Oracle WebCenter itself is also a stateful application. Therefore, you must configure state replication in cluster scenarios. For more information on how state replication works in Oracle WebLogic Server, see Oracle Fusion Middleware Using Clusters for Oracle WebLogic Server. Oracle WebLogic Server supports two types of state replication: ■ In-memory replication - Using in-memory replication, Oracle WebLogic Server copies a session state from one server instance to another. The primary server creates a primary session state on the server to which the client first connects, and a secondary replica on another WebLogic Server instance in the cluster. The replica is kept up to date so that it may be used if the server that hosts the servlet fails. ■ JDBC-based persistence - In JDBC-based persistence, Oracle WebLogic Server maintains the HTTP session state of a servlet or JSP using file-based or database-based persistence. Properly configuring state replication requires both configuring the environment and configuring the application properly. For information on state replication behavior under failover conditions see Section 6.3.2.8, Expected Behavior for Application Failover. For more information on diagnosing state replication issues see Section 6.3.2.5, Oracle WebCenter State Replication. Configuring High Availability for Oracle ADF and WebCenter Applications 6-41

6.3.2.6 Understanding the Distributed Java Object Cache

Oracle WebCenter applications use a distributed Java Object Cache for greater performance. Configure this cache across all Oracle WebCenter clusters, with one distributed cache per cluster. Table 6–6 lists some examples of the type of objects which Oracle WebCenter places in the Java Object Cache. Collaboration Collaboration services cache objects in the Java Object Cache on a per user session basis. These cached user sessions are destroyed when the HTTP session is destroyed. Worklist Worklist caches the called items so that unless the refresh button is clicked, or the every fifteen minute refresh poll is triggered, the same items are displayed as the user changes the sort and group by settings. The display is also cached by group and sort order settings, updating when a change occurs. This is read only data which, if not present, is fetched and stored on the cache. Oracle WebCenter Spaces The list of all templates and public spaces are maintained in the Java Object Cache. This is shared by all users, in addition to the list of group spaces and templates that a particular user can access. These are cached per user. A template created on one JVM Table 6–6 Oracle WebCenter Object Types for Java Object Cache Oracle WebCenter Component Object Cached Discussions service Topics and forums Announcements service Announcements Instant Messaging and Presence service Presence subscription lists Users presencesubscription status Worklist service Called Worklist items, such that cached data is used until refresh is called. Content Integration Oracle Portal JCR: type information and metadata obtained from the repository. Service Framework User profile. Queried usernames. Recent Activity Recent activity results per user. WebCenter Spaces Global list of group spaces and group space templates in the application. List of group spaces and group space templates that a user can access. Page Service List of pages in a scope. WSRP Server Preference store values for WSRP producers. Documents service Provisioning and configuration checks for the Documents service configured for an Oracle WebCenter Spaces application Profile management Lightweight user profile objects Navigation service List of active Navigation Model objects Portlet Consumer Portlet markup 6-42 Oracle Fusion Middleware High Availability Guide does not show up if the template cache has been initialized in another JVM, unless JOC distributes the data, or an administrator in the second JVM does an explicit refresh where the cache is rebuilt. Documents Service The Documents service uses Java Object Cache to cache provisioning and configuration checks for document services, as applies to Oracle WebCenter Spaces application configuration. For provisioning, cached objects are flagged as distributed. They are replicated by a correctly configured Java Object Cache in a high availability environment, the configuration cached state is kept locally. All cached objects are flagged to expire after one minute. Caching reduces the number of times UCM calls are made to check the state of the UCM Server, as Oracle WebCenter Spaces repeatedly checks provisioning and configuration to control service rendering in the UI. Portlet Consumer The portlet consumer caches portlet mark-up in the Java Object Cache according to the cache headers in the portlet response. The cache can be expires based or validation based. Profile Management caches the lightweight user profile objects in Java Object Cache. If particular profile data is not found, it will queried from the backend and the cache would be populated. The number of objects stored have an upper bound of 1000 and are in the Java Object Cache for one hour. Navigation caches the Navigation Model objects in the Java Object Cache on a per user session basis. These cached objects are destroyed when the HTTP session is destroyed. Recent Activity The list of recent activity results are cached for each user to prevent a requery of results each time the recent activity task flow or RSS feed is viewed. The cache is automatically refreshed every fifteen minutes, or can be manually refreshed using the refresh icon in the recent activity task flow. For Java Object Cache configuration procedures, see Section 6.4.13, Configuring the Java Object Cache.

6.3.2.7 Oracle WebCenter Protection from Failover and Expected Behavior