Oracle WebLogic Server 12c Essentials Practice Tests and PDFs

http://my-java-planet.blogspot.com/2014/04/which-weblogic-optimization-allows-one.html

JMS queue A staging area that contains messages that have been sent and are waiting to be read. Note that, contrary to what the name queue suggests, messages don't have to be delivered in the order sent. A JMS queue only guarantees that each message is processed only once. Incorrect: Not B: (Only one queue required) * A distributed destination is a set of destinations (queues or topics) that are accessible as a single, logical destination to a client. A distributed destination has the following characteristics: It is referenced by its own JNDI name. Members of the set are usually distributed across multiple servers within a cluster, with each destination member belonging to a separate JMS server. * A distributed queue is a set of physical JMS queue members. As such, a distributed queue can be used to create a QueueSender, QueueReceiver, and a QueueBrowser. The fact that a distributed queue represents multiple physical queues is mostly transparent to your application. Not Topic: JMS topic A distribution mechanism for publishing messages that are delivered to multiple subscribers.

Note:

Note: * Types of Security Roles: Global Roles and Scoped Roles There are two types of security roles in WebLogic Server: / A global security role can be used in any security policy. Oracle provides several default global roles that you can use out of the box to secure your WebLogic resource / A scoped role can be used only in policies that are defined for a specific instance of a WebLogic resource (such as a method on an EJB or a branch of a JNDI tree). You might never need to use scoped roles. They are provided for their flexibility and are an extra feature for advanced customers. Incorrect: Not E: Role mapping is the process whereby principals (users or groups) are dynamically mapped to security roles at runtime. In WebLogic Server, a Role Mapping provider determines what security roles apply to the principals stored a subject when the subject is attempting to perform an operation on a WebLogic resource. Because this operation usually involves gaining access to the WebLogic resource, Role Mapping providers are typically used with Authorization providers.

Active GridLink for Oracle RAC In Oracle WebLogic Server 10.3.4, a single data source implementation has been introduced to support an Oracle RAC cluster. It responds to FAN events to provide Fast Connection Failover (FCF), Runtime Connection Load-Balancing (RCLB), and RAC instance graceful shutdown. XA affinity is supported at the global transaction Id level. The new feature is called WebLogic Active GridLink for RAC; which is implemented as the GridLink data source within WebLogic Server. Note: * The WebLogic Server JDBC subsystem has supported Oracle RAC since WLS version 9.0, originally developed for Oracle9i RAC. This support is based on a particular type of data source configuration, called a multi data source. A multi data source is a data source abstraction over one or more individual data sources. It serves JDBC connections from each of the member data sources according to a specified policy. A RAC multi data source configuration requires that each member data source obtain connections to a particular RAC instance. Reference: How-To: Use Oracle WebLogic Server with a JDBC GridLink Data Source

Restrictions on Production Redeployment Updates WebLogic Server can host a maximum of two different versions of an application at one time. Note: * When you redeploy a new version of an application, you cannot change: An application's deployment targets An application's security model A Web application's persistent store settings To change any of the above features, you must first undeploy the active version of the application. Incorrect: * (not A) Production redeployment enables you to update and redeploy an application in a production environment without stopping the application or otherwise interrupting the application's availability to clients. Production redeployment saves you the trouble of scheduling application downtime, setting up redundant servers to host new application versions, manually managing client access to multiple application versions, and manually retiring older versions of an application. * (not C) Not dependant on whether the application is JRockit or Hotspot. * (not E) The production redeployment strategy is supported for: Standalone Web Application (WAR) modules and enterprise applications (EARs) whose clients access the application via a Web application (HTTP). Enterprise applications that are accessed by inbound JMS messages from a global JMS destination, or from inbound JCA requests. All types of Web Services, including conversational and reliable Web Services, but not 8.x Web Services. Production redeployment is not supported for: Standalone EJB or RAR modules. If you attempt to use production redeployment with such modules, WebLogic Server rejects the redeployment request. To redeploy such modules, remove their version identifiers and explicitly redeploy the modules. Applications that use JTS drivers. For more information on JDBC application module limitations, see JDBC Application Module Limitations in Configuring and Managing JDBC Data Sources for Oracle WebLogic Server. Applications that obtain JDBC data sources via the DriverManager API; in order to use production redeployment, an application must instead use JNDI to look up data sources. Applications that include EJB 1.1 container-managed persistence (CMP) EJBs. To use production redeployment with applications that include CMP EJBs, use EJB 2.x CMP instead of EJB 1.1 CMP. Reference: Reference; Deploying Applications to Oracle WebLogic Server 12c, Redeploying Applications in a Production Environment

Reference: Oracle WebLogic Server Active GridLink for Oracle Real Application Clusters(RAC)

Note: * It is recommended that you shutdown WebLogic Server instances through the Administration Console. * If automatic server migration is enabled, the servers are required to contact the cluster leader and renew their leases periodically. Servers will shut themselves down if they are unable to renew their leases. The failed servers will then be automatically migrated to the machines in the majority partition.