DB2 JDBC and Data Source Configuration:

---- Go to JDBC providers under Resources.

In scope selection drop-down list select

Node = app_Node01

Click New.
Provide Database type: DB2
Provider type: DB2 Universal JDBC Driver Provider.
Implementation type: Connection pool data source
Name: It will take default after provide above details (DB2 Universal JDBC Driver Provider).
Click Next.
Provide the db2jcc.jar file location.
Click Next.

Click Finish.

Click Review.
Check synchronize changes with Nodes.

Click Save.
Click Ok.
--- Go to Resources select Data Sources under JDBC.
Click New.
Provide Data source name = DB2DS
JNDI name = jdbc/DB2DS

Click Next.
Select DB2 Universal JDBC Driver Provider under select an existing JDBC provider radio button.

Click Next.
Provide Driver type = 4 (Default)
Database name = SAMPLE.
Server name = rajasekhar-pc
Port number = 50000 (Default)
Check CMP (Default it checked)
Click Next.

Click Next.
Click Finish.

Click Review.
Check Synchronize changes with Nodes.

Click Save.
Click Ok.

Click DB2DS.
Under Related items select JAAS – J2c Authentication data.
Click New.
Provide Alias = DB2_det
User ID = db2admin
Password = admin

Click Apply.

Click Review.
Check Synchronize changes with Nodes.

Click Save.

Click Ok.
---- Go to Resources. Select Data Sources under JDBC.
Click on DB2DS.
Select dmgr_Node01/DB2_det under Component-managed authentication alias.

Click Apply.
Click Review.
Check Synchronize changes with Nodes.

Click Save.

Click ok.
Click on Test Connection.
For the first time when you click the Test connection it will through the error.
Because of synch not happened, for that we have to stop the node on AppSrv01 profile and do the
synchronization and start the node.

Click ok.
Synch Command.

Click Ok.
Start App_srv01 Node.

----- Go to Resources. Select Data Sources under JDBC.

Click Test Connection.

Connection Succesful.
JDBC Providers:
It indicates what type of database we are using, what type of implementation mechanism
either XA or connection pool data source we are using.

Implementation Types:
1) Connection pool Data Source - Single phase commit.
2) XA Data Source – Two phase commit.

Connection Pool:
It contains predefined connection objects; Server won’t create a new connection object
every time. It will use the connection objects from the connection pool parameters.

Connection pool Properties:

Connection Timeout:
Specify the interval, in seconds, after which a connection request times out and a
ConnectionWaitTimeoutException is thrown. This action can occur when the pool is at its maximum (Max
Connections) and all of the connections are in use by other applications for the duration of the wait. For
example, if Connection Timeout is set to 300 and the maximum number of connections is reached, the
Pool Manager waits for 300 seconds for an available physical connection. If a physical connection is not
available within this time, the Pool Manager throws a ConnectionWaitTimeoutException.
Min Connections:
Specify the minimum number of physical connections to be maintained. Until this number is
reached, the pool maintenance thread does not discard any physical connections. However, no attempt is
made to bring the number of connections up to this number. For example, if Min Connections is set to 3,
and one physical connection is created, that connection is not discarded by the Unused Timeout thread.
By the same token, the thread does not automatically create two additional physical connections to reach
the Min Connections setting.

Tip: Set Min Connections to zero (0) if the following conditions are true:
 You have a firewall between the application server and database server.
 Your systems are not busy 24x7.
Max Connections:
Specify the maximum number of physical connections that can be created in this pool.
These connections are the physical connections to the database. After this number is reached, no new
physical connections are created and the requester waits until a physical connection that is currently in
use is returned to the pool or a ConnectionWaitTimeoutException is thrown. For example, if Max
Connections is set to 5, and there are five physical connections in use, the Pool Manager waits for the
amount of time specified in Connection Timeout for a physical connection to become free. If, after that
time, there are still no free connections, the Pool Manager throws a ConnectionWaitTimeoutException to
the application.
Unused Time out:
Specify the interval in seconds after which an unused or idle connection is discarded.
Tips:
 Set the Unused Timeout value higher than the Reap Timeout value for optimal performance.
Unused physical connections are only discarded if the current number of connections not in use
exceeds the Min Connections setting.
 Make sure that the database server’s timeout for connections exceeds the Unused timeout
property specified here. Long lived connections are normal and desirable for performance.
For example, if the unused timeout value is set to 120, and the pool maintenance thread is enabled (Reap
Time is not 0), any physical connection that remains unused for two minutes is discarded. Note that
accuracy of this timeout and performance are affected by the Reap Time value.
Aged Time out:
Specify the interval in seconds before a physical connection is discarded, regardless of
recent usage activity.
Setting Aged Timeout to 0 allows active physical connections to remain in the pool indefinitely. For
example, if the Aged Timeout value is set to 1200 and the Reap Time value is not 0, any physical
connection that remains in existence for 1200 seconds (20 minutes) is discarded from the pool. Note that
accuracy of this timeout and performance are affected by the Reap Time value.
Tip: Set the Aged Timeout value higher than the Reap Timeout value for optimal performance.
Reap Time out:
Specify the interval, in seconds, between runs of the pool maintenance thread. For example, if
Reap Time is set to 60, the pool maintenance thread runs every 60 seconds. The Reap Time interval
affects the accuracy of the Unused Timeout and Aged Timeout settings. The smaller the interval you set,
the greater the accuracy. When the pool maintenance thread runs, it discards any connections that are
unused for longer than the time value specified in Unused Timeout, until it reaches the number of
connections specified in Min Connections. The pool maintenance thread also discards any connections
that remain active longer than the time value specified in Aged Timeout.
Tip: If the pool maintenance thread is enabled, set the Reap Time value less than the values of Unused
Timeout and Aged Timeout. The Reap Time interval also affects performance. Smaller intervals mean
that the pool maintenance thread runs more often and degrades performance.

Purge Policy:
Specify how to purge connections when a stale connection or fatal connection error is detected.
Valid values are EntirePool and FailingConnectionOnly. If you choose EntirePool, all physical connections
in the pool are destroyed when a stale connection is detected. If you choose FailingConnectionOnly, the
pool attempts to destroy only the stale connection. The other connections remain in the pool. Final
destruction of connections that are in use at the time of the error might be delayed. However, those
connections are never returned to the pool.
Tip: Many applications do not handle a StaleConnectionException in the code. Test
and ensure that your applications can handle them.

---- Go to Resources. Select Data Sources under JDBC.

Click on OracleDS or DB2DS.

Click on Connection pool properties.

Application Deployment:
We can deploy an application in 4 different ways.
1) Adminconsole.
2) Scripting. [Jacl (java control language – in WAS 6.0)/Jython – will use from WAS 6.1
onwards].
3) Application Server Tool Kit.
4) Rapid Deployment (or) Hard deployment.

Deployment in WAS 6.0 versions:

---- Go to WAS root.
C:\IBM_ND_6.0\WebSphere\AppServer\installableApps – Here you can find some installable
applications. (Some of the applications with an extension .ear [enterprise archive] and some
applications with an extension .war [web archive]).

Steps to Deploy an Application:

Login to dmgr console.
Expand Applications. Select Enterprise Applications.
Select install and browse where the application (.ear or .war) is available. If it is a .war file
provide the context root.
Specify the application parameters.
Application name, installation location, target for the location.
Map data sources and ejb’s with JNDI and specify the host name.
Save the changes and start the application.

Process:
---- Take a backup of the application.
Go to Enterprise applications under Applications.
Check the PlantsByWebSphere

Click on Export.

Click on PlantsByWebsphere to download .ear file.

Click on save.

Click Back.
Click Save changes.

Click save.

------ Check the PlantsByWebsphere Application.

Click Uninstall.

Click Ok.
Click Save Changes.

Click Save.

------ Select Enterprise Applications or Install New Applications.

Specify the path of .ear or .war module to upload and install.

Click Next.
Click Next.

Click Continue.
Click Next.

Click Apply.

Click Next.
Click Next.
Click Next.
In Step 5 No need to change any thing.
Click Next.
In step 6 No need to change any thing.

Click Next.
In step 7 No need to change any thing.

Click Next.
In Step 8 No need to change any thing.

Click Next.
Click Continue.
In step 9 Select Default_host under Virtual host.

Click Next.
In Step 10 No need to change any thing.

Click Next.
Click Finish.

Click Save to Master Configuration.

Check Synchronize changes with Nodes.

Click Save.
Click Save.
---- If server were not in stop Mode we have to start the server.
----- Go to Enterprise applications.
Check PlantsByWebsphere.

Click Start.
---- To know under which server the PlantsByWebSphere
---- Click on PlantsByWebSphere.

Click Target Mappings.