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, cross-
domain 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 META-
J2EE WAR App INF/weblogic-application.xml library-ref
Web App Shared Libraries referenced from the WARs WEB-
INF/weblogic.xml library-ref
EJB Shared Libraries referenced from the EJB-JARs META-INF/
SOA libraries packaged separately outside of
weblogic-ejb-jar.xml library-ref
soa-infra J2EE app, requiring common classes
Libraries referenced from within each JARs META-INF/MANIFEST.MF
e.g. Coherence to be in the System class path
Class-Path:<lib>
BPEL generated code uses filter class loaders to
Shared Utility classes loaded in the EARs APP-INF/lib and classes
avoid conflicts from code in the class path
WAR/RAR in App One class loader per WAR and RAR. Use APP-INF/lib to share classes.
Shared Library examples: SOA Ext, Fusion ESS
Loads WEB-INF/Classes and WEB-INF/lib

SOA Domain Directory Structure

$DOMAIN_HOME/bin Start/Stop and Set Env scripts Difference between MBean and JNDI Name in config.xml
$DOMAIN_HOME/config Configuration root and config.xml MBean Names used by JMX subsystem, points to managed beans that
$DOMAIN_HOME/deployed-composites Cache of deployed composites corresponds to the object. It is scoped at the domain level i.e. should be
$DOMAIN_HOME/lib uniquely named per domain (reason for one SOA per domain).
Domain-wide app classes
$DOMAIN_HOME/servers/<servername> Logs/cache for Managed Servers 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 weblogic-
application.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 Loads config from local store (if Administration Server) or connecting to Administration Server (if Managed Server). Loads internal services.
STANDBY Start deploying the applications.
ADMIN Listening, but will accept requests from admin users. Joins cluster.
RESUMING Transition state from ADMIN to RUNNING.
RUNNING Running and ready to service all requests.
SHUTDOWN Stop deployments, services and shutdown.
FAILED 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.