WebLogic Server Essentials Cheat Sheet

WebLogic Server Concepts

A domain is a logically related group of server resources. It has one special instance called Administration
Server, which is a central point to configure and manage the domain resources, and other instances called
Managed Servers , which host the actual applications. Managed Servers maintain a read-only copy of the
configuration that it obtains from the Administration Server on startup.
A cluster is a collection of two or more Managed Servers that provide failover and load balancing. All
domain configurations are stored in $DOMAIN_HOME/config/config.xml, which can be hosted on a
shared drive, or on one of the boxes for servers to pack/unpack.
Do not change configuration manually or on Managed Servers. Always use the Administration Server to ensure no changes are lost.
Applications/services are targeted to run on Managed Servers, or to a cluster, which automatically targets to all Managed Servers in that cluster. Most
services are deployed homogeneously on all server instances in acluster, enabling transparent failover from one server to another. Certain pinned services
such as JMS and JTA are targeted at individual server instances, and support failure recovery with migratable servers. Node Manager is an optional, crossdomain daemon process on each machine, providing server start/restart/monitoring capabilities and is required for whole server migration. It is
configured in nodemanager.domains and nodemanager.properties.
Note that there can be only ONE SOA installation per domain, either targeted to one Managed Server or one cluster.
WebLogic Server Class Loading Hierarchy
Key Principles: Delegation, Visibility, Uniqueness. Classloader Analysis Tool at http://<host>:<port>/wls-cat/
JVM
Bootstrap
Loads core JDK/JRE classes
Extension
Classes under jre/lib/ext
System
Classes from $CLASSPATH i.e. jars/classes
References in META-INF/MANIFEST.MF Class-Path:<lib>
WLS
Domain Extension
Classes under $DOMAIN_HOME/lib applies to all apps/clusters
Filtering Classloader <prefer-application-packages> in weblogic-application.xml
J2EE EAR App
Each app receives its own classloader hierarchy i.e. one for all JARs in the app.
J2EE JAR App
Enterprise App Shared Libraries referenced from the EARs METAJ2EE WAR App
INF/weblogic-application.xml library-ref
Web App Shared Libraries referenced from the WARs WEBINF/weblogic.xml library-ref
EJB Shared Libraries referenced from the EJB-JARs META-INF/

weblogic-ejb-jar.xml library-ref
Libraries referenced from within each JARs META-INF/MANIFEST.MF
Class-Path:<lib>

Shared Utility classes loaded in the EARs APP-INF/lib and classes

WAR/RAR in App
One class loader per WAR and RAR. Use APP-INF/lib to share classes.

Loads WEB-INF/Classes and WEB-INF/lib

SOA libraries packaged separately outside of

soa-infra J2EE app, requiring common classes
e.g. Coherence to be in the System class path
BPEL generated code uses filter class loaders to
avoid conflicts from code in the class path
Shared Library examples: SOA Ext, Fusion ESS

SOA Domain Directory Structure

$DOMAIN_HOME/bin
$DOMAIN_HOME/config
$DOMAIN_HOME/deployed-composites
$DOMAIN_HOME/lib
$DOMAIN_HOME/servers/<servername>

Start/Stop and Set Env scripts

Configuration root and config.xml
Cache of deployed composites
Domain-wide app classes
Logs/cache for Managed Servers

Difference between MBean and JNDI Name in config.xml

MBean Names used by JMX subsystem, points to managed beans that
corresponds to the object. It is scoped at the domain level i.e. should be
uniquely named per domain (reason for one SOA per domain).
JNDI Name points to the actual object and is scoped at the cluster level.

Threading Model
WebLogic Server handles all requests asynchronously using a single, priority based, self-tuning queue. The queue processing is performed by the thread
pool using policy constraints specified by Work Managers. Thread pool size is decided based on CPUs/cores. Default settings provide equal load balancing
among Work Managers and can be customized using a fair share request class. Socket Muxer threads multiplex multi-protocol incoming requests (e.g.
HTTP/T3) from the socket, set up context information, determine the Work Manager to use and places the request in the execute queue.
Use Cases (take care not to over-use these, which defeats the purpose of self-tuning threads):
Thread Starvation (A calls B calls A) Specify <min-threads-constraint>
Back-end Hogging all Threads Specify <max-threads-constraint>
Use Deamon Threads for long running processes (e.g. SOA engine) -- avoids STUCK warnings
Work Manager Usage:
Configure Work Manager scope at server config.xml, application weblogicapplication.xml or module (takes precedence) weblogic-ejb-jar.xml/weblogic.xml
using <self-tuning> parameters.
Map Work Managers to application/modules using <dispatch-policy> element.

Page 2
Transaction Management
Global Transaction (XA)

Involves more than one resource manager

e.g. JMS and Database

High overhead due to JTA log maintenance

Supports Guaranteed Message Delivery with

EXACTLY ONCE delivery

Local Transaction

Involves only one resource manager e.g. even if across

multiple database schemas (reason FA uses AQ vs. JMS)

Low overhead

Supports Guaranteed Message Delivery with EXACTLY

ONCE delivery

No Transaction

Involves no resource manager e.g. web service

invocations

Lowest overhead

Supports Guaranteed Message Delivery with AT

LEAST ONCE delivery using WS-RM web services

Guaranteed Message Delivery is an exchange of acknowledgements between sender and receiver to ensure message delivery. It does not depend on global

transactions. It is also possible with no transactions e.g. when using web services with WS-RM.
Consistency across multiple applications depends on transaction boundaries. It does not depend on global transactions. e.g. debit()->process()>credit() is guaranteed even with local transactions, and if the process() is asynchronous, it will be eventually consistent.
Transaction Timeouts can be specified at domain level or superseded at application level (e.g. BPEL EJB Timeout). It is read when initiating transactions e.g.

BPEL invoked via WS call or callbacks uses application level timeout, but if invoked via JMS Adapter (with existing transaction) uses domain level timeout.
WebLogic Server Lifecycle States
STARTING
STANDBY
ADMIN
RESUMING
RUNNING
SHUTDOWN
FAILED

Loads config from local store (if Administration Server) or connecting to Administration Server (if Managed Server). Loads internal services.
Start deploying the applications.
Listening, but will accept requests from admin users. Joins cluster.
Transition state from ADMIN to RUNNING.
Running and ready to service all requests.
Stop deployments, services and shutdown.
Stuck, OOM or other internal errors. If before ADMIN state, will shutdown, else will stay in ADMIN state.

oracle.com/SOA

blogs.oracle.com/SOA

@OracleSOA

OracleSOA

Oracle SOA 2013 Oracle Corporation. All rights reserved.