1Z0-599 Practice Questions

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

A:

* Troubleshooting Slow Response Time from the Client and Low Database Usage

These symptoms are usually caused by a bottleneck upstream of the database, perhaps in the JDBC

connectionpooling. Monitor the active JDBC connections in the WebLogic Console and watch for

excessive waiters and wait times; increase the pool size, if necessary.

* Attribute: Maximum Capacity

Maximum number of physical database connections that this connection pool can contain. Different

JDBC Drivers and database servers may limit the number of possible physical connections.

C: Attribute: Statement Cache Size

The algorithm used to maintain the statement cache:

LRU - After the statementCacheSize is met, the Least Recently Used statement is removed when a

new statement is used.

Fixed - The first statementCacheSize number of statements is stored and stay fixed in the cache. No

new statements are cached unless the cache is manually cleared.

E: If the queue appears starved but adding execute threads does not improve performance,

there may be resource contention. Because CPU utilization is low, the threads are probably

spending much of their time waiting for some resource, quite often a database connection.

Use the JDBC monitoring facilities in the console to check for high levels of waiters or long

wait times. Adding connections to the JDBC connection pool may be all that is required to

fix the problem.

Note:

* If you had a JDBC connection pool where the Initial Capacity and Maximum Capacity attributes

were different, you might want to create a gauge monitor to monitor the maximum and minimum

number of connections.

By setting the Threshold Low value to be one less than the Initial Capacity, your gauge monitor

trapcould monitor the ActiveConnectionsCurrentCount attribute of the JDBCDataSourceRuntime

MBean and alert you whenever the number of active connections are less than the Initial Capacity

(which might indicate database connectivity problems).

The following principles encourage RESTful applications to be simple, lightweight, and fast:

* Resource identification through URI

* Uniform interface: Resources are manipulated using a fixed set of four create, read, update, delete

operations: PUT, GET, POST, and DELETE. PUT creates a new resource, which can be then deleted by

using DELETE. GET retrieves the current state of a resource in some representation. POST transfers a

new state onto a resource. See Responding to HTTP Methods and Requests for more information.

* Self-descriptive messages

* Stateful interactions through hyperlinks

Reference: The Java EE 6 Tutorial, What Are RESTful Web Services?

To manage work in your applications, you define one or more of the following Work Manager

components:

Fair Share Request Class:

Response Time Request Class:

Min Threads Constraint:

Max Threads Constraint:

Capacity Constraint

Context Request Class:

Note:

* max-threads-constraint—This constraint limits the number of concurrent threads executing

requests from the constrained work set. The default is unlimited. For example, consider a constraint

defined with maximum threads of 10 and shared by 3 entry points. The scheduling logic ensures that

not more than 10 threads are executing requests from the three entry points combined.

A max-threads-constraint can be defined in terms of a the availability of resource that requests

depend upon, such as a connection pool.

A max-threads-constraint might, but does not necessarily, prevent a request class from taking its fair

share of threads or meeting its response time goal. Once the constraint is reached the server does

not schedule requests of this type until the number of concurrent executions falls below the limit.

The server then schedules work based on the fair share or response time goal.

* WebLogic Server prioritizes work and allocates threads based on an execution model that takes

into account administrator-defined parameters and actual run-time performance and throughput.

Administrators can configure a set of scheduling guidelines and associate them with one or more

applications, or with particular application components.

* WebLogic Server uses a single thread pool, in which all types of work are executed. WebLogic

Server prioritizes work based on rules you define, and run-time metrics, including the actual time it

takes to execute a request and the rate at which requests are entering and leaving the pool.

The common thread pool changes its size automatically to maximize throughput. The queue

monitors throughput over time and based on history, determines whether to adjust the thread

count. For example, if historical throughput statistics indicate that a higher thread count increased

throughput, WebLogic increases the thread count. Similarly, if statistics indicate that fewer threads

did not reduce throughput, WebLogic decreases the thread count. This new strategy makes it easier

for administrators to allocate processing resources and manage performance, avoiding the effort and

complexity involved in configuring, monitoring, and tuning custom executes queues.

Reference: Using Work Managers to Optimize Scheduled Work

Note:

* In managing multiple servers, Node Manager uses multiple configuration files and outputs log files

to multiple directories.

* nodemanager.domains

This file contains mappings between the names of domains managed by Node Manager and their

corresponding directories.

* Node Manager in the WebLogic Server Environment

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/1Z0-599/page_28_img_1.jpg

Reference; Node Manager Administrator's Guide for Oracle WebLogic Server 12c

When an application that

a shared library or package is deployed, WebLogic Server checks

the names and version string requirements against the libraries registered with the server. If an exact

match for a library or package name is not found, or if the version requirements are not met, the

application deployment fails.

If WebLogic Server finds a name and version string match for all of the libraries referenced in the

application, the server adds the libraries' classes to the classpath of the referencing application and

merges deployment descriptors from both the application and libraries in memory. The resulting

deployed application appears as if the referenced libraries were bundled with the application itself.

Note:

As a best practice, your development team should always include version string information for a

library or optional package in the manifest file for the deployment. See Editing Manifest Entries for

Shared Libraries in Developing Applications for Oracle WebLogic Server for more information.

If you are deploying a library or package that does not include version string information, you can

specify it at the command line using one or both of the following options:

libspecver—Defines a specification version for the library or package.

libimplver—Specifies an implementation version for the library or package.

Reference: Deploying Applications to Oracle WebLogic Server, Deploying Shared Java EE Libraries and

Dependent Applications

Note:

* Example

If you have additional Coherence caches running on Coherence*Web, then you must merge the

cache configuration information (typically defined in the coherence-cache-config.xml file) with the

session configuration contained in the session-cache-config.xml file. The cache and session

configuration must be consistent across WebLogic Server and Coherence cache servers.

The WebLogic Server Management Pack EE greatly improves application

performance by providing unique functionality to automatically detect performance

bottlenecks; quickly diagnose these performance problems, and identify their root

cause. Key application performance management features of the pack include the

following:

* (A) Manage multiple farms and WebLogic Domains centrally

* Monitor Oracle Coherence Cluster – including all nodes within a cluster, all

caches, services, connection managers and connections

* Monitor middleware availability and performance out-of-box; track such data

historically, and receive notifications of potential problems

* Obtain real-time, in-depth JVM diagnostics without instrumentation overhead

* Trace transactions across containers as well as to the database

* (E) Analyze call paths and dependencies via graphical, architecture views

* (E) Automatically discover and model dependencies between Java components,

frameworks, and web services

Reference: Weblogic Server Management Pack Enterprise Edition

WebLogic Administrators typically use the Administration Console or the WebLogic Scripting Tool

(WLST) to create and deploy (target) JDBC modules.

Note:

* (not A) Domain template—defines the full set of resources within a domain, including

infrastructure components, applications, services, security options, and general

environment and operating system options.

* Extension template—defines the applications and services that you can add to an

existing domain, including product component functionality and resources such as

JDBC or JMS.

* (not B) Each domain describes its configuration in an XML document that is located in the domain’s

configuration directory. At run time, each WebLogic Server instance in a given domain creates an in-

memory representation of the configuration described in this document.

The central configuration file for a domain is DOMAIN_NAME/config/config.xml. This file specifies

the name of the domain and the configuration of each server instance, cluster, resource, and service

in the domain. The file includes

to additional XML files that are stored in subdirectories of

theDOMAIN_NAME/config directory. These included files are used to describe major subsystems of

WebLogic Server.

Reference: Configuring WebLogic JDBC Resource

C: Message Unit-of-Order is a WebLogic Server value-added feature that enables a stand-alone

message producer, or a group of producers acting as one, to group messages into a single unit with

respect to the processing order. This single unit is called a Unit-of-Order and requires that all

messages from that unit be processed sequentially in the order they were created.

D Transactions required for parallel processing.

Incorrect:

A: Many applications need an even more restricted notion of a group than provided by the Message

Unit-of-Order (UOO) feature. If this is the case for your applications, WebLogic JMS provides the

Unit-of-Work (UOW) Message Groups, which allows applications to send JMS messages, identifying

some of them as a group and allowing a JMS consumer to process them as such. For example, an JMS

producer can designate a set of messages that need to be delivered to a single client without

interruption, so that the messages can be processed as a unit. Further, the client will not be blocked

waiting for the completion of one unit when there is another unit that is already complete.

Note:

* WebLogic JMS defines two default connection factories, which you can look up using the following

JNDI names:

weblogic.jms.ConnectionFactory

weblogic.jms.XAConnectionFactory

Reference: Using Message Unit-of-Order