201.Explain about HTTP Session State Replication in WLS?

    1. Oracle WebLogic Server provides clustering support for JSPs and servlets by replicating the HTTP session state.
    2. To benefit from HTTP session state clustering, you must ensure that the session state is persistent, by configuring:
      • In-memory replication
      • JDBC replication
      • File system replication
    3. You must also access the cluster via a collection of Web servers with identically configured proxy plug-ins or load-balancing hardware.
    4. Session persistence is configured using the <session-descriptor> element in the weblogic.xml deployment descriptor file.
      • Each persistence method has its own set of configurable parameters.

202.Explain about Replication Groups in WLS?

    1. A replication group is a logical grouping of related servers in a cluster.
    2. WLS enables you to determine where to put backup objects using replication groups.
    3. WLS attempts to:
      • Send backup objects to a preferred secondary replication group, if it is configured
      • Send backup objects to a different machine
      • Avoid sending backup objects to servers in the same replication group

203.What is the user of Replication Groups in WLS?

    1. Replication groups:
      • Represent a subset of servers within a cluster
      • Help to determine the placement of secondary sessions (avoid replicating within the same room, for example)
      • Are not explicitly defined in the console-like machines and clusters
    2. WLS attempts to:
      1. Send secondary sessions to servers that are assigned to the preferred secondary replication group of the primary server
      2. Avoid sending secondary sessions to servers that are assigned to the same replication group as the primary server

204.Explain about In-Memory Replication in WLS?

    1. Each user’s session always exists on two servers:
      • Primary
      • Secondary
    2. Every update to the primary session is automatically replicated on the secondary server, either:
      • Synchronously (default)
      • Asynchronously (batch)
    3. WLS can replicate:
      • HttpSession objects
      • Stateful session EJBs
    4. Session objects exist on only two servers.
    5. Secondary:
      • The server is determined by the replication group and machine definition.
      • The object is created immediately after the primary object is created.
    6. Primary failure makes the backup object the primary object.

205.What are all the Requirements for In-Memory Replication in WLS?

    1. Subsequent requests from the same client must have access to the same primary object.
    2. To use in-memory replication for the HTTP session state, clients must access the cluster using either:
      1. The load-balancing hardware (WLS aware)
      2. A collection of Web servers, or a single Web server, with WebLogic proxy plug-ins (configured identically)
      3. Oracle WebLogic Server configured with HTTPClusterServlet

206.How will you Configuring In-Memory Replication in WLS?

  1. Configure the proxy server (if applicable).
  2. Optionally define replication groups and/or machines.
  3. Specify the persistence type in the weblogic.xml deployment descriptor; the options include:
      1. replicated
      2. replicated_if_clustered
      3. async-replication-across-cluster

207.Explain about JDBC Replication in WLS?

      • HTTP sessions are persisted to a database using a common JDBC data source.
      • The required data definition language (DDL) file is available in the documentation.
      • All members of the cluster have access to any client’s session for failover purposes (no primary or secondary).
      • All server instances have access to all sessions.
      • Subsequent requests from the same client can be handled by any server.
      1. Great failover capability
      2. Significant performance reduction
      • Changing session objects causes (slow) database synchronization.

      203.What is the user of Replication Groups in WLS?

        • Replication groups:
          • Represent a subset of servers within a cluster
          • Help to determine the placement of secondary sessions (avoid replicating within the same room, for example)
          • Are not explicitly defined in the console-like machines and clusters
        • WLS attempts to:
          • Send secondary sessions to servers that are assigned to the preferred secondary replication group of the primary server
          • Avoid sending secondary sessions to servers that are assigned to the same replication group as the primary server

      204.Explain about In-Memory Replication in WLS?

        • Each user’s session always exists on two servers:
          • Primary
          • Secondary
        • Every update to the primary session is automatically replicated on the secondary server, either:
          • Synchronously (default)
          • Asynchronously (batch)
        • WLS can replicate:
          • HttpSession objects
          • Stateful session EJBs
        • Session objects exist on only two servers.
        • Secondary:
          • The server is determined by the replication group and machine definition.
          • The object is created immediately after the primary object is created.
        • Primary failure makes the backup object the primary object.

      205.What are all the Requirements for In-Memory Replication in WLS?

        • Subsequent requests from the same client must have access to the same primary object.
        • To use in-memory replication for the HTTP session state, clients must access the cluster using either:
          • The load-balancing hardware (WLS aware)
          • A collection of Web servers, or a single Web server, with WebLogic proxy plug-ins (configured identically)
          • Oracle WebLogic Server configured with HTTPClusterServlet

      206.How will you Configuring In-Memory Replication in WLS?

      • Configure the proxy server (if applicable).
      • Optionally define replication groups and/or machines.
      • Specify the persistence type in the weblogic.xml deployment descriptor; the options include:
          • replicated
          • replicated_if_clustered
          • async-replication-across-cluster

      207.Explain about JDBC Replication in WLS?

        • HTTP sessions are persisted to a database using a common JDBC data source.
        • The required data definition language (DDL) file is available in the documentation.
        • All members of the cluster have access to any client’s session for failover purposes (no primary or secondary).
        • All server instances have access to all sessions.
        • Subsequent requests from the same client can be handled by any server.
          • Great failover capability
          • Significant performance reduction
        • Changing session objects causes (slow) database synchronization.

      208.How will you Configuring JDBC Replication in WLS?

      • Create the required table in the database.
      • Create a JDBC data source that has read/write privileges for your database.
      • Configure JDBC session persistence in the weblogic.xml deployment descriptor.

      Ex:
      <session-descriptor>
         <persistent-store-type>jdbc</persistent-store-type>
         <persistent-store-pool>MyDataSource</persistent-store-pool>
      </session-descriptor>
      209.JDBC Persistent Table Configuration
       A database table named WL_SERVLET_SESSIONS must exist with read/write access:
      dss
      210.Explain about File Replication?
      File replication is similar to JDBC replication, but it persists sessions to a highly available file system.

        • Session state may also be stored in a file.
        • For file-based persistence:
          • You must create the directory in which to store the file
          • The file must have the appropriate access privileges