JDBC

JDBC means for Java Database Connectivity, which is a standard Java API for database-independent connectivity between the Java programming language and a wide range of databases.

The JDBC library includes APIs for each of the tasks commonly associated with database usage:

•    Making a connection to a database
•    Creating SQL or MySQL statements
•    Executing that SQL or MySQL queries in the database
•    Viewing & Modifying the resulting records

WebSphere application server provide the JDBC with resource adapter ( Data source ) 

For Database connection with WebSphere application server we have to follow the below procedure : 

1.    Creating the Env variable for the jdbc client jar files 
2.    Creating the JDBC Provider.   

3.    Creating the DataSource.          

• Adding and modifying the Connection pool properties. 

Read More

Data Source

Configuring the Non-XA Data Source

To configure the non-XA data source and credentials:
1.       Go to Resources, JDBC, Data sources.
2.       For nonclustered server environments, select the same cell scope then click New.
3.       For clustered server environments, select the same cluster scope then click New.
4.       In the Data source name field, type a name for the non-XA data source, for example, ORM Non-XA Data source.
5.       In the JNDI name field, type orm/jdbc/ORMServerDS, and then click Next.
6.       Choose an existing JDBC provider and select the non-XA JDBC provider, for example, Oracle JDBC Driver, and then click Next.
7.       In the URL field, type the JDBC connection URL:
jdbc:oracle:thin:@<server>[:<port>]:<database_name>

For example:
jdbc:oracle:thin:@localhost:1521:orcl

8.       Select Oracle10g data store helper from the list, and then click Next.
9.       Click Finish.
10.   Click the name of the new non-XA data source to display details.
11.   In the Container-managed authentication alias list, select the database alias and then click Apply.
The reference to this option being deprecated can be ignored.
12.   On the same page, in the Additional Properties section, click Connection Pool Properties and set the Maximum connections to 30.
13.   Click OK.

Configuring the Transaction (XA) Data Source

To configure the XA data source:
1.       Go to Resources, JDBC, Data sources.
2.       For nonclustered server environments, select the same cell scope, then click New.
3.       For clustered server environments, select the same cluster scope, then click New.
4.       In the Data source name field, type a name for the XA data source, for example,
Datasource name- RFM XA Data source.
5.       In the JNDI name field, provide the JNDI name for the datasource, and then click Next.
6.       Choose an existing JDBC provider and select the XA JDBC provider, for example, Oracle JDBC Driver (XA), and then click Next.
7.       In the URL field, type the JDBC connection URL:
jdbc:oracle:thin:@<server>[:<port>]:<database_name>

For example:
jdbc:oracle:thin:@localhost:1521:orcl

8.       Select Oracle10g data store helper from the list, and then click Next.
Note: You must use Oracle11g data store helper for Oracle 11g database.
9.       Click Finish.
10.   Click the name of the XA data source to display details.
11.   In the Container-managed authentication alias list, select the database alias, and then click Apply.
The reference to this option being deprecated can be ignored.
12.   On the same page, in the Additional Properties section, click Connection Pool Properties and set the Maximum connections to 30.
13.   Click OK.
14.   Click Apply, and then click Save directly to master configuration.

Read More

ContextManage E createInstance Could not load class: com.ibm.ws.security.auth.ContextManagerImpl

Issue :: 

while starting the dmgr or JVM or Nodeagent in websphere 7.0 causing problems

ContextManage E   createInstance Could not load class: com.ibm.ws.security.auth.ContextManagerImpl

Cause ::

Cause: security.xml file is corrupted 

Résolution ::

       please check the security.xml file size . if its corrupted it show as 0 size and check the last date time of the file  .

       If you found the file is corrupted . 

You could replace the corrupted file with the same file from the Deployment Manager's repository. 

Restart whole cell ( nodeagent and dmgr and JVM's ) its will fix the issue . 

Read More

WSVR0703W

Problem 

After stopping the WebSphere Application Server, it does not restart and in the native_stdout.log we see the below error :
.
WSVR0703W
com.ibm.ws.runtime.WsServer
java.lang.NoClassDefFoundError:
org.eclipse.hyades.logging.events.cbe.impl.EventFactoryContext
at com.ibm.ejs.ras.Tr.<clinit>(Tr.java:304)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
at com.ibm.ejs.ras.RasHelper.setServer(RasHelper.java:249)
at com.ibm.ws.runtime.WsServer.<clinit>(WsServer.java:50)
..........
at com.ibm.wsspi.bootstrap.WSPreLauncher.main(WSPreLauncher.java:111)
Caused by: java.lang.ClassNotFoundException:
org.eclipse.hyades.logging.events.cbe.impl.EventFactoryContext
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:402)
.
Cause
 Possible osgi class cache got corrupted

Resolution :: 

Run the following steps in order to clear Websphere class caches :

.
- cd IBM/WebSphere/AppServer/profiles/Dmgr01/bin
- run ./clearClassCache.sh
- run ./osgiCfgInit.sh
- cd /tmp/ to confirm that javasharedresources folder is gone
- remove the contents of the following directories:
- profile_root/temp/
- profile_root/wstemp/
- profile_root/config/temp/

then run ./startNode.sh

Also see reference TN:

"How to clear the WebSphere class caches"
http://www-01.ibm.com/support/docview.wss?uid=swg21607887 

Above info find on :: 

http://www-01.ibm.com/support/docview.wss?uid=swg21672201

Read More

WSVR0232E

Problem(Abstract)

The deployment manager JVM fails to start.
Symptom

The SystemOut.log file shows the following errors:

WSVR0232E: Unable to resolve cross document link identified by the uri:  
serverindex.xml#NamedEndPoint_1188855255542, and referenced by document  serverindex.xml        

WSVR0009E: Error occurred during startup
com.ibm.ws.exception.ConfigurationError: com.ibm.ws.exception.ConfigurationError: Exception encountered while extracting configuration information for the Name Space


Cause

The following entry is seen in the serverindex.xml file for one of the nodes in the cell:

<specialEndpoints href="serverindex.xml#NamedEndPoint_1188855255542" />

Resolving the problem

The problem can be resolved by removing the entry from the serverindex.xml file.

    Find the serverindex.xml for the node that contains the NamedEndPoint entry in the WSVR0232E message.


    <DMGR_Profile_Home>/config/cells/cell_name/nodes/node_name/serverindex.xml

    Backup the serverindex.xml file outside of the IBM® WebSphere® Application Server install path if needed.

    Remove the following entries that match the NamedEndPoint in the WSVR0232E messages:


    <specialEndpoints href="serverindex.xml#NamedEndPoint_1188855255542" />

    Save the serverindex.xml file.

    Start the dmgr.

    Issue the SyncNode command from the nodes to synchronize the changes.

Above info find from ::

http://www-01.ibm.com/support/docview.wss?uid=swg21285710

Read More

WTRN0037W

Problem(Abstract)

When WebSphere Application Server attempts to recover Oracle database transactions, the following exception is issued:

WTRN0037W: The transaction service encountered an error on an xa_recover operation. The resource was com.ibm.ws.rsadapter.spi.WSRdbXaResourceImpl@1114a62. The error code was XAER_RMERR. The exception stack trace follows: javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.recover(OracleXAResource.java:726)
at com.ibm.ws.rsadapter.spi.WSRdbXaResourceImpl.recover(WSRdbXaResourceImpl.java:954)
at com.ibm.ws.Transaction.JTA.XARminst.recover(XARminst.java:137)
at com.ibm.ws.Transaction.JTA.XARecoveryData.recover(XARecoveryData.java:609)
at com.ibm.ws.Transaction.JTA.PartnerLogTable.recover(PartnerLogTable.java:511)
at com.ibm.ws.Transaction.JTA.RecoveryManager.resync(RecoveryManager.java:1784)
at com.ibm.ws.Transaction.JTA.RecoveryManager.run(RecoveryManager.java:2241)
Cause

Oracle requires that you have special permissions to attempt to perform the recovery.
If there is a system crash during a distributed transaction, the WebSphere Application Server transaction manager will attempt to clean up any failed transactions which it finds in the transaction logs.
When the recovery involves an Oracle XAResource, the Oracle JDBC driver
oracle.jdbc.xa.OracleXAResource.recover function will make a call to DIST_TXN_SYNC.

The above error occurs when the user trying to execute the .recover method does not have sufficient privileges to make a call to DIST_TXN_SYNC.

Environment

This problem can occur with all versions of Oracle: 8i, 9i, 10g, and 11g.

Resolving the problem

Run the following commands as user SYS:

 grant select on pending_trans$ to <user>;
grant select on dba_2pc_pending to <user>;
grant select on dba_pending_transactions to <user>;
grant execute on dbms_system to <user>;  (If using Oracle 10.2.0.3 or lower JDBC driver)
grant execute on dbms_xa to <user>; (If using Oracle 10.2.0.4 or higher JDBC driver)

Where <user> is the username configured in the Oracle datasource's authentication alias.

This problem is mentioned under Oracle bug: 3979190. Running the preceding commands solve the problem.

Update: Since the SYS.DBMS_SYSTEM package contains many procedures, granting execute privileges to that package gives access to all of them. In Oracle patch 5892995 (JDBC driver) and 5945463 (server), Oracle has moved the DIST_TXN_SYNC procedure to a new package called DBMS_XA. These patches are available in 10.2.0.4 and higher. By using the new DBMS_XA package, it will reduce the security risk which DBMS_SYSTEM might cause.

If the recovery of the inflight transactions is not important, then one possible workaround to this problem is to remove the transaction logs. (Does NOT apply to WebSphere Process Server and IBM Business Process Manager, please see note below for details)

The transaction logs are stored in the following folder:
<WebSphere Application Server_install_root>\profiles\<PROFILE_NAME>\tranlog\<CELL_NAME>\<NODE_NAME>\<SERVER_NAME>\transaction

To remove the transaction logs, do the following:
(1) Stop the server.
(2) Delete the '\transaction' folder and all subdirectories.
(3) Restart the server.
The above exceptions will no longer occur.


NOTE: Transaction logs should NOT be deleted if running in a WebSphere Process Server or IBM Business Process Manager environment.
The WebSphere Process Server and IBM Business Process Manager systems can get into an inconsistent state because the logs are tightly coupled with information in other places like BPEDB, WPSDB, SIB messages and MQ, if it is configured.

Above info taken from :: 

http://www-01.ibm.com/support/docview.wss?uid=swg21196663

Read More

J2CA0045E: Connection not available

    J2CA0045E: Connection not available

    Error:

    [DATE DateXX GMT] 0000076d FreePool E J2CA0045E: Connection not available while invoking method createOrWaitForConnection for resource
     jdbc/XXX.
       Their is no change in the environment as well as on the application.

    Issue solution:

    J2CA0045E messages and from the javacore that the connection pool is full (50 threads). In order to diagnose the most efficient way is to run a trace and collect the connection leak logic data as per the following technote –

    How to troubleshoot J2CA0045E connection pooling problems

    http://www-01.ibm.com/support/docview.wss?uid=swg21385033

    One pre-requisite of this is to ensure you are on a fixpack level which includes the apar PK83902 which for V6.0.x is 6.0.2.37. This apar includes the diagnostic code necessary. I see that you are very back level at 6.0.2.19 ? Before we go any further please can you confirm to me whether it is going to be possible for you to upgrade to this later fixpack level and if not then please explain so we can progress this accordingly.

    J2CA0045E errors along with connection time out exceptions which happens normally when the JDBC connection pool is maxed out and all new incoming connection requests have to be queued waiting for a connection to become free on the JDBC connection pool. The javacore files showed upwards of 50 threads that were waiting for a datasource connection. This can typically occur for one of three reasons: either the maximum pool size value is too small, connections are not being closed by the application, or connections are not being returned to the free pool even after being closed by the application until the Local Transaction Containment (LTC) is completed.

    To remedy a pool size that is too small, increase the maximum pool size value. Keep in mind that the maximum pool size value is per jvm, so if the application is deployed to a cluster, each cluster member will maintain its own pool. Therefore, the database server will need to be able to receive a total number of connections which is calculated by the maximum pool size value times the number of jvm's in the cluster.

    http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/udat_conpoolset.html

    To remedy an application that is not closing connections, consult with you application developer to ensure the application is properly implementing the get/use/close scenario. An application has  to always call close() method on a jdbc conenction whenever its done using it for the connection to be returned back to the free pool. If an application fails to close a jdbc connection after done using it, it will not be returned to the pool and after a while a the connection pool will run out of connections and J2CA0045E will be logged into the systemout. For this, I highly recommend that you double check with your application developers that they do infact follow the get/use/close patter whereby a JDBC connection is retrieved from a jdbc conneciton pool, used and the closed upon being done used.

    To remedy connections that are not being returned to the free pool until the LTC is completed, the application should obtain an unshared connection instead of a shared connection. This can be accomplished in one of two ways. The common method is to program the application to perform an indirect lookup of the datasource via a resource reference (using the java:comp/env/name_of_resource_reference syntax). In addition to reprogramming the application to perform an indirect lookup, a resource reference will need to be created within the application. The jndi name of the datasource will be configured on the resource reference along with setting the sharing scope to unshared. The application will need to be redeployed after this is done. This is discussed further in the following document...

    How to change from shared to unshared connections

    http://www-01.ibm.com/support/docview.wss?uid=swg21223465

    The second means of setting the application to obtain an unshared connection would be to configure one of two new datasource custom properties: defaultConnectionTypeOverride or globalConnectionTypeOverride. However, these custom properties are not available until FixPack v6.1.0.23. You would need to upgrade WebSphere Application Server to at least v6.1.0.23 to be able to configure one of the custom properties. The benefit of the custom properties is that it alleviates the need to reconfigure the application to perform the indirect datasource lookup as discussed above. Following are two links to documents which describe the two custom properties...

    PK75717: ADD CUSTOM PROPERTIES TO CONTROL CONNECTION SHARING

    http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg1PK75717

    Tuning connection pools (see the last section under "Control connection pool sharing")

    http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/tdat_conpoolman.html

    We can also obtain additional data by enabling connection pool tracing. This will help in clarifying which of the above recommendations is most appropriate. Following is a link to the connection pool MustGather document...MustGather: Connection pooling problems for WebSphere Application Server

    http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg21254645

    Tracing can be enabled dynamically, which does not require a restart of the application server, by following the procedure under "Dynamic trace" in the following document...Setting up a trace

    http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg21254706

    Set the maximum trace file size to 250MB and the number of historical files to 10.

Read More