Deployment Methods Of Weblogic Server| Weblogic Server Deployment Methods

Deployment Methods Of Weblogic Server

• WLS supports three deployment methods:

             –Console deployment

             –Command-line deployment

             –Autodeployment

• Applications and EJBs can be deployed in an:

             –Archived file (.ear, .war, .jar)

             –Exploded (open) directory format

Deployment Process Of Weblogic Server| Weblogic Server Deployment Process

 Deployment Process Of Weblogic Server| Weblogic Server Deployment Process

Deploying an application involves the following tasks:

• Preparing: Choosing whether to package the application as an archived file or keep it in an exploded directory
• Configuring: Creating a deployment plan to maintain the configuration changes without changing the deployment descriptors
• Deploying: Targeting and distributing the application to servers in an Oracle WebLogic Server domain

              –Install or deploy

              –Update or redeploy

            –Delete or undeploy

Weblogic Server Deployment Basics

 Weblogic Server Deployment Basics

Overview of Deployment:

____________________

Two views of deployment:

 • Developers :

       –Development environment

       –Single stand-alone machine

       –Deploy over and over again at will during the testing phase

  • Administrators:

        –Production environment

        –Multiple WebLogic Server instances or clusters

What Is Deployed?

 Deploy Java EE application in:

• Exploded form:

              –Directory structure very important

              –Easier to update individual pieces

              –Harder to keep track of the whole collection

• Archive form

             –Similar to tar or zip, can be maintained with those tools

             –Type: .jar, .war, .ear, .rar, and so on

             –Contains code, metacode, descriptors (xml), directories

Node Manager Overview In Weblogic

Node Manager Overview In Weblogic

What Node Managers Can Do ?

________________________

• You can use Node Managers to:

–Start, shut down, and restart an administration server

–Start, shut down, suspend, and restart managed servers

–Automatically restart the administration and managed servers on failure

–Monitor servers and collect log data

• Node Managers:

–Run on the same computers as the managed servers

–Can be run automatically in the background, as Windows services or UNIX daemons

–Are available as either Java-based or (for UNIX only) script-based processes.

Node Manager Architecture:

_______________________

  

How a Node Manager Starts an Administration Server ?

_____________________________________________

How a Node Manager Starts a Managed Server ?

______________________________________

How a Node Manager Restarts an Administration Server ?

______________________________________________

How a Node Manager Restarts a Managed Server ?

________________________________________

How a Node Manager Shuts Down a Server Instance ?

__________________________________________

Versions of Node Managers:

______________________

• There are two versions of Node Managers:

–Java-based Node Managers

–Script-based Node Managers

• Java-based Node Managers run within a Java Virtual Machine (JVM) process.
• Script-based Node Managers (used only for UNIX systems) do not have as much security, but provides the ability to remotely manage servers over a network using Secure Shell (SSH).
• Node Managers are required for:

–Whole server migration

–Some configurations of automatic server migration.

JDBC Performance Tuning| Performance Tuning Of JDBC

JDBC Performance Tuning

What Is JDBC?

JDBC is an API for accessing databases in a uniform way.

JDBC provides:

• Platform independent access to databases
• Location transparency
• Transparency to proprietary database issues

JDBC Architecture:

Following are the Parameters useful for tuning the JDBC:

1)   Connection Pool Size:

• The connection pool size in WebLogic Server can be controlled through the following parameters.
• Initial Capacity –Maximum Capacity –Capacity Increment
• Server performance can be improved by tuning these parameters.
• For applications involving heavy database traffic, consider having Initial and Maximum capacity to be the same.

2)   Shrink Frequency:

• WebLogic Server periodically shrinks the connection pool to its initial capacity based on the usage.
• The Shrink Frequency parameter is used to specify the number of seconds to wait before shrinking a connection pool.
• When set to 0, shrinking is disabled. This can be helpful in a production environment.

3)   Testing Connections:

• WebLogic Server can test a connection from the connection pool before giving it to a client.

This is specified by enabling the Test Connection On Reserve parameter.

• Connections can also be tested periodically for validity.

This is specified by the  Test Frequency parameter.

• Both these parameters can degrade performance.

4)   Row Prefetch:

• Row prefetching improves performance by fetching multiple rows from the server to the client in one server access.
• The optimal prefetch size depends on the particulars of the query.
• In general, increasing this number will increase performance, until a particular value is reached.

     Note: This is applicable only for external clients, not for clients in the same JVM as WebLogic Server.

5)   Statement Cache:

• The three types of statements in JDBC are:

–Statements (not cached)

–Prepared statements

–Callable statements

• WebLogic Server provides a Statement Cache where JDBC statements can be cached for reuse.
• Tuning the cache parameters can improve performance.

6)   PinnedToThread:

• WebLogic Server pins a database connection from the connection pool to an execution thread the first time an application uses the thread to reserve a connection.
• This can improve performance, as there is no contention by the threads for reserving a connection from the connection pool.

7)   Batch Updates:

• A typical application might involve multiple data manipulation statements (insert, update, delete).
• Combining them as appropriate can help improve performance.
• Statement.addBatch() and Statement.executeBatch() can help in batching updates.

8)   Combining Transactions:

• Transaction operations are expensive and can significantly degrade performance.
• Combining multiple operations into a single transaction can help improve performance.
• By default, JDBC connections have auto-commit enabled.

–Every JDBC statement is executed as a separate transaction.

–You can use Connection.setAutoCommit(false) to turn this off.

–You can use Connection.start(), Connection.commit(), and Connection.rollback() to demarcate transactions.