18 Threading and Clustering Topics

Learn how to use threads in WebLogic Server as well as how to program applications for use in WebLogic Server clusters.

Using Threads in WebLogic Server

WebLogic Server is a sophisticated, multi-threaded application server and it carefully manages resource allocation, concurrency, and thread synchronization for the modules it hosts. To obtain the greatest advantage from WebLogic Server's architecture, construct your application modules according to the standard Jakarta EE APIs.

In most cases, avoid application designs that require creating new threads in server-side modules:

  • Applications that create their own threads do not scale well. Threads in the JVM are a limited resource that must be allocated thoughtfully. Your applications may break or cause WebLogic Server to thrash when the server load increases. Problems such as deadlocks and thread starvation may not appear until the application is under a heavy load.

  • Multithreaded modules are complex and difficult to debug. Interactions between application-generated threads and WebLogic Server threads are especially difficult to anticipate and analyze.

When independent repository queries can run concurrently, submit them as tasks to a container-provided jakarta.enterprise.concurrent.ManagedExecutorService. Use ManagedScheduledExecutorService for scheduled work. WebLogic Server supplies the default executor at java:comp/DefaultManagedExecutorService. The container manages the execution resources and associates supported application context with each task. Do not create an application-owned Thread or Executors pool as a substitute inside EJB business code; follow the threading restrictions of the component model. A managed thread factory is available where explicit managed threads are appropriate, subject to those component rules.

Bound concurrent work and configure the managed resource’s limits for the workload. Use completion/timeout handling appropriate to the request; avoid waiting while holding locks or other resources needed by the submitted tasks. Treat shared application state as concurrent state, and follow the component’s rules for resource access. Do not assume a task inherits the submitting transaction.

Applications submit work to the managed resource but do not own its lifecycle: do not call shutdown, shutdownNow or close on an injected/lookup managed executor. Make tasks respond to cancellation and interruption and release their resources.

Review the design for deadlocks and thread starvation, and test the managed concurrent workload under representative and overload conditions.

Unmanaged background threads can outlive an application deployment and retain its classloader, resources or application state, whether they are daemon or non-daemon threads. Daemon status controls JVM shutdown participation; it does not provide application lifecycle management. Use managed concurrency resources and make tasks honor interruption/cancellation so that work can finish and release resources when the application stops or is redeployed.

Be sure to test multithreaded code under increasingly heavy loads, adding clients even to the point of failure. Observe the application performance and WebLogic Server behavior and then add checks to prevent failures from occurring in production.

See Configuring Concurrent Managed Objects in Administering Server Environments for Oracle WebLogic Server

Package this CDI bean in an application with annotated bean discovery enabled. Obtain it through container injection rather than new RepositoryTasks(), so the managed executor resource is injected. Pass a thread-safe Callable<String> implementing an independent repository query. submit returns a Future; its caller must handle completion, failure, cancellation and any required timeout. The container owns the executor; this bean does not create a thread pool or shut down the executor.

package examples.concurrent;

import java.util.concurrent.Callable;
import java.util.concurrent.Future;
import jakarta.annotation.Resource;
import jakarta.enterprise.concurrent.ManagedExecutorService;
import jakarta.enterprise.context.ApplicationScoped;

@ApplicationScoped
public class RepositoryTasks {
    @Resource(lookup = "java:comp/DefaultManagedExecutorService")
    private ManagedExecutorService executor;

    public Future<String> submit(Callable<String> query) {
        return executor.submit(query);
    }
}

Thread Scheduling APIs

WebLogic Server schedules concurrent work through its Work Manager infrastructure and provides Jakarta Concurrency services and CommonJ APIs for application programming.

WebLogic Server provides several interfaces for submitting and scheduling concurrent work.

  • WebLogic Work Manager APIs: The weblogic.work package contains WebLogic-specific scheduling interfaces, including weblogic.work.WorkManager and WorkManagerFactory. WorkManager.schedule(Runnable) submits work to a Work Manager.

  • Jakarta Concurrency services: Use jakarta.enterprise.concurrent.ManagedExecutorService to submit Runnable or Callable tasks, and ManagedScheduledExecutorService for delayed or periodic execution. The container manages execution resources, the supported application context and lifecycle. Methods such as submit return Future handles for completion and result handling. Use these standard services for new portable Jakarta EE concurrency code, subject to the component model’s threading rules. See Using Threads in WebLogic Server above and Configuring Concurrent Managed Objects in Administering Server Environments for Oracle WebLogic Server.

  • CommonJ APIs: The commonj.work.WorkManager API submits commonj.work.Work instances and returns WorkItem handles. Its waitForAll and waitForAny methods let a caller wait for submitted work items. The commonj.timers.TimerManager API provides timer scheduling. Existing CommonJ applications can continue to use these supported APIs. See Using the Timer and Work Manager API in Developing CommonJ Applications for Oracle WebLogic Server.

Work Manager request classes and constraints control scheduling of associated server work. Managed concurrency services and CommonJ work submissions integrate with the WebLogic scheduling infrastructure; their application APIs and context/lifecycle contracts remain distinct. Concurrent execution can improve throughput or reduce response latency for suitable independent work, but results depend on resource limits, contention and workload.

For scheduling configuration, see Using Work Managers to Optimize Scheduled Work in Administering Server Environments for Oracle WebLogic Server.

Programming Applications for WebLogic Server Clusters

There are certain requirements and restrictions when you deploy JSPs and servlets, and EJBs to a WebLogic Server cluster. Also you need to understand the implications of binding clustered objects in the JNDI tree when you develop EJBs or custom RMI objects in a cluster.

JSPs and servlets that will be deployed to a WebLogic Server cluster must observe certain requirements for preserving session data. See Requirements for HTTP Session State Replication in Administering Clusters for Oracle WebLogic Server for more information.

EJBs deployed in a WebLogic Server cluster have certain restrictions based on EJB type. See Understanding WebLogic Enterprise JavaBeans in Developing Jakarta Enterprise Beans Using Deployment Descriptors for information about the capabilities of different EJB types in a cluster. EJBs can be deployed to a cluster by setting clustering properties in the EJB deployment descriptor.

If you are developing either EJBs or custom RMI objects for deployment in a cluster, also refer to Using WebLogic JNDI in a Clustered Environment in Developing JNDI Applications for Oracle WebLogic Server to understand the implications of binding clustered objects in the JNDI tree.