What are the Deployment tips in Weblogic server?

WebLogic Server allows you to store deployment units either as a single archive file, or as an exploded directory that contains the same contents of the archive file.

An archive file is a single file that contains all of an application’s or module’s classes, static files, directories, and deployment descriptor files.

Deploy user applications on managed server instances. This separates the administration application (console) and the domain configurations from user applications.

Avoid using automatic deployment of applications in production and multiple-server environments. Running the WebLogic domain in “Production Mode” will disable the automatic deployment in production. If you create scripts for deploying applications as a part of an overall build, consider using the wldeploy Ant task.

If you deploy an application (or module) with the On Future Redeploys option set to Ignore Roles and Policies From DD one or more times before setting it to Initialize Roles and Policies From DD, you can set security policies and security roles using the admin console. But these changes using admin console will override security specified in deployment descriptors.

Tips:

    Use production mode to run production applications.

    Avoid deploying user applications on admin server instance.

    To specify the server’s default Web application, use an empty context-root element or an element with a value “/” in the weblogic.xml or application.xml file.

    Changing security policies for an application after deployment in the admin console overrides the policies in the deployment descriptor.

Redeployment:

Once you deploy an application, you can redeploy the application itself or selected parts of the application. Redeploying an entire application involves unloading all its classes and then deploying the application again with the changed files. Redeploying an application in production is a serious undertaking that can affect performance, so plan application updates carefully.

If a Web application is in production and in use, redeploying causes WebLogic Server to lose all active HTTP sessions. HTTP session can be restore by turning a special property ON in the WebLogic specific deployment descriptor file (weblogic.xml).

Tips:

    If you have modified only static files, it is possible to refresh them without redeploying the entire application.

    Use command-line option to partially redeploy an expanded application (weblogic.Deployer … -redeploy …).

    For changing deployment parameters without changing the application, use alternate deployment descriptors.

    To simplify re-distributing application archives to multiple WebLogic Server instances during redeployment use stage mode deployment.

    A managed server with all application staged can be started and be made fully functional in independence mode if admin server is not available.

Enterprise Application:

WebLogic optimizes EJB access, if the client is within the same enterprise application classes and libraries can be shared across all archive applications within the enterprise application. So consider creating enterprise archives rather than deploying related applications independently.

Also Enterprise-wide settings can be used, rather than multiple local settings in deployment descriptors. Create JDBC resources in the WebLogic Server domain, using the WebLogic console, rather than employing the weblogic-application.xml technique.

Tips:

    Avoid deploying EJB archives and related Web applications as separate independent applications in WebLogic Server.

    Improved runtime performance can be achieved when Web components access EJB components within the same enterprise application.

    The enterprise can be deployed as one deployment unit.

    Do not place application-specific classes or JAR files in the system classpath (to avoid having to restart the server for reloading them).

    When using WebLogic Server 8.1, use the new APP-INF/lib and APP-INF/classes directories in the enterprise-application directory structure, to simplify the packaging of utility classes and utility archives.

Pre-compilation:

Production and test deployments should include precompiled JSP pages and EJBs (use weblogic.appc or weblogic.jspc/weblogic.ejbc with earlier weblogic versions). They can catch compile-time errors in applications long before you deploy them. Also offline compilation validates the deployment descriptors for compliance with current specifications.

Deploying compiled applications reduces deployment time and subsequent server restart time. Development deployments intended for use on the developer’s workstation can use on-the-fly compilation.

Tips:

    To precompile JSP files during application deployment or server startup, enable the precompile parameter in weblogic.jar.

    To disable pagecheck and recompilation at runtime in a production environment, set pageCheckSeconds to -1.

    You can use weblogic.appc or weblogic.ejbc (deprecated) to compile EJBs outside the server VM. This reduces the subsequent server restart time.

    Use the weblogic.Deployer utility, or its associated Ant task, wldeploy, in scripts to automate deployment in production environments.

Deployment Descriptor Editing:

Changing the deployment descriptor of a J2EE application takes effect only when the application is redeployed. The WebLogic admin console provides a way to change some deployment descriptor attributes without redeploying the application. To take advantage of this feature, you must to deploy the application in exploded directory structure (non-archived format), when the domain is running in development mode.

To change descriptor values of the application after deployment (as exploded format) go to Web Application Module > Your Application > Configuration tab > Descriptor tab.

Tips:

    Use tools provided with WebLogic Server to generate and edit XML deployment descriptors.

    WebLogic Builder generates descriptors; it includes an interface for editing descriptors.

    DDInit is a command-line utility for generating deployment descriptors for WebLogic Server applications.

    ddcreate is an Ant task that can be used for creating deployment descriptors for enterprise applications.

EJB:

A stateless session EJB free pool improves performance and throughput as beans are created at server startup or deployment time. WebLogic Server uses a cache of bean instances to improve the performance of stateful session EJBs. The cache stores active EJB instances in memory so that they are immediately available for client requests.

Using application-level/combined cache will result in reduced fragmentation, better utilization of memory and heap space. But the use of application-level/combined cache is limited to entity EJBs in an enterprise application. For an application that requires high throughput, use bean-level caching. Bean-level caching is effective because tasks do not compete for control of the one thread of control in a combined cache.

To make use of WebLogic provided optimization of calls made to EJB components within an application, set to true.

The same can also be achieved by writing local interfaces for EJBs for access within the same enterprise application.

Concurrency strategies for entity EJBs include:

Database:

Improves throughput by deferring to database (for EJB 1.1 and 2.0, this is the default and recommended mechanism)

Exclusive:

Avoids deadlocks; use it only if a high level of consistency is required on non-clustered servers

Optimistic:

No lock will be held in the EJB container or database during transaction. But the EJB container ensures that the data being updated by a transaction has not been changed.

Read-only:

Container does not attempt to save a bean’s state at the end of a transaction; use this for EJBs that do not make any change to persistent data. With the read-only strategy, use to invalidate cached bean data in the container; this updates the data from the persistent store when a timeout occurs.

Tips:

    Consider the number of execute threads, to configure maximum number of beans in the free pool.

    To limit the memory used by a stateful session EJB, set the maximum number of beans that can reside in the cache (max-beans-in-cache).

    Too small cache causes frequent activation and passivation.

    Too large a cache wastes memory.

    LRU algorithm keeps a bean in the passive state after it passes the ideal number timeout seconds.

    To avoid the associated overhead of passivating stateful session EJBs, use the not recently used (NRU) algorithm

    Local interfaces for EJBs provide optimized access for server-side EJB clients.

    Combined cache enables the administrator to tune just one cache, rather than multiple caches, in weblogic-application.xml.

    Message-driven beans that use container-managed transactions must use XA connection factories.