WebLogic JDBC Interview Questions

(1) What is JDBC?

Java Database Connectivity is a Java API which is used for accessing the database

(2) What is a data source?
A JDBC data source is an object bound to the JNDI tree that provides database connectivity through a pool of JDBC connections

(3) What is a connection pool?
Connection pool is a group of connections which are used to create physical database connections

(4) What are the advantages of connection pool?

• It provides re-usability of database connections
• It provides Readily Available Connections
• You can test the connection (Test Connection on Reserve) before giving it to an application
• No hard coding is required. You can change host name, service name, port etc., in WebLogic Admin Console 

(5) When JDBC Connections are created?

• When starting up WebLogic Server 
• When deploying the connection pool to a target server or cluster 

(6) What are the different types of WebLogic Server JDBC Data Sources?

• Generic Data Sources
• Multi Data Sources
• Grid Link Data Sources

(7) What is a Generic Data Source?

It provides database connectivity through a pool of JDBC connections

(8) What is Multi Data Source?
Multi Data Source is an abstraction around group of databases which provides either load balancing or fail-over

(9) What is a Grid Link Data Source?

Grid Link  Data Source is a data source which provides connectivity between WebLogic Server and an Oracle RAC (Real Application Cluster) Database. The Grid Link Data Source is introduced from WebLogic Server 10.3.4.

(10) What are the algorithms supported by Multi Data Source?

• Load Balancing
• Fail-over

(11) What will happen to in-use connections if one of the data source in Multi Data source fails?

The Multi data source does not provide fail-over for active and in-use connections.

(12) What are the advantages of GridLink data source?
GridLink Data Source provides:

• Fast Connection Fail-over
• Runtime Connection Load Balancing 
• GridLink Affinity

13) What is FAN?
FAN stands for Fast Application Notification events. Enabling FAN Events allows a data source to subscribe to and process Oracle Fast Application Notification (FAN) events.

(14) What is ONS?
Oracle Notification Service (ONS) is used to adaptively respond to state changes in an Oracle RAC instance.  ONS Client will connect to a list of ONS daemon listen addresses and port for receiving ONS-based FAN events.

You can enable FAN Events by

• Select Fan Enabled
• Provide a comma-separate list of ONS daemon listen addresses and ports for receiving ONS-based FAN events. You can use Single Client Access Name (SCAN) addresses to access FAN notifications.

(15) What is the default database listen port?

1521

(16) What is the default ONS listen port?
6200

(17) What is JDBC URL?
It is the URL of the database to connect to. Data base locations are specified using a JDBC Uniform Resource Locator (URL). The format of the URL varies by JDBC driver.

Examples for JDBC URL:
jdbc:oracle:thin:@<database host>:<db listener port>/<database service name>


(18) What are the different types of JDBC Drivers?

• Type 1 Driver ( JDBC-ODBC Driver)
• Type 2 Driver ( Native Driver)
• Type 3 Driver ( Network Driver)
• Type 4 Driver (Pure Java Driver)

(19) What are the databases supported by Oracle WebLogic?

• Orace Database
• Sybase
• MySQL
• DB2
• Pointbase
• Microsoft SQL Server etc  (for more information refer the oracle documentation)

(20) What is the difference between XA driver & Non-XA driver?
 XA stands for eXtended Architecture, which is used to support Global Transactions.
Non-XA stands for non-eXtended Architecture which is used to support Location Transactions

 
(21) What is the difference between Local transactions & Global transactions?
A transaction which involves single database is known as local transaction.
A transaction which involves multiple databases is known as Global transaction.

 
(22) What is LLR?

 
(23) Which JNDI name is used in  applications in case of Multi Data Source?
You need to use the JNDI name that you have used while creating a multi data source in WebLogic

 
(24) Total number of JDBC connections?

(25) What is data source targeting & un-targeting?

You can select one or more targets to deploy your new JDBC data source. If you don't select a target, the data source will be created but not deployed. You will need to deploy the data source at a later time. Un-targeting a datasource is deselection the data source targets

(26) What is oracle.net.CONNECT_TIMEOUT?
The property oracle.net.CONNECT_TIMEOUT helps to set the login time out in Oracle.

 
(27) What is oracle.jdbc.ReadTimeout ?
The property oracle.jdbc.ReadTimeout helps to set read timeout while reading from the socket.

(28) What is the difference between thin driver & thick driver?

(29)  What is Test Connections On Reserve?
It enables WebLogic Server to test a connection before giving it to a client. (It requires that you specify a Test Table Name)

(30) What is Test Frequency?
It is the number of seconds a WebLogic Server instance waits between attempts when testing unused connections.(It requires that you specify a Test Table Name.) Connections that fail the test are closed and reopened to re-establish a valid physical connection. If the test fails again, the connection will be closed

(31) What is Shrink Frequency?  
The number of seconds to wait before shrinking a connection pool that has incrementally increased to meet demand. Default value 900 seconds(15mins)

(32) What is Inactive Connection Timeout?
The number of inactive seconds on a reserved connection before WebLogic Server reclaims the connection and releases it back into the connection pool. If you set the Inactive Connection Timeout feature to a positive value, the WebLogic server reclaims the leaked connections

(33) What happen if you select the "Fan Enabled" during Grid Link data source creation?  
It enables the data source to subscribe to and process Oracle FAN events.

(34) What is the use of ONS nodes?
A comma-separate list of ONS daemon listen addresses and ports to which connect to for receiving ONS-based FAN events.
Example: <ONS Scan Address>:6200 or <ONSHOST1>:6200,<ONSHOST2>:6200

(35) What is the use of Profile Connection Leak?
This is used to collect profile information about threads that have reserved a connection from the data source and the connection leaked (was not properly returned to the pool of connections).
Set the Inactive Connection Timeout feature to a positive value to reclaim leaked connection.

(36) What are different data source control operations that you can perform?

• Shrink
• Reset
• Clear Statement Cache
• Suspend
• Resume
• Shutdown
• Resume

(37) What is the use of Capacity Increment Attribute?

WebLogic first uses the existing connections available in the pool when a connection request is issued. If there are no connections available, this parameter takes care of creating a new connection.
In WebLogic Server 10.3.1 and higher releases, the Capacity Increment attribute is no longer configurable and is set to a value of 1.

(38) Difference between MinCapacity & InitialCapacity?

The MinCapacity attribute sets the minimum number of physical connections that a connection pool can contain after it is initialized.
The Minimum Capacity parameter was added in WebLogic Server 10.3.6.
The InitialCapacity value that previously handled both the initial and minimum capacity for the pool this has been split into two attributes:

• MinCapacity defaults to InitialCapacity if not set; InitialCapacity continues to default to 1.
• MinCapacity is only used for shrinking calculations only. It is lazy in that the minimum connections are not created when the server starts up; InitialCapacity is used for this function.
• For upward compatibility, InitialCapacity is used if MinCapacity is not set.

(39) What will you do if the database is down during WebLogic Servers start-up? 

If a data source connection cannot be established with the database during startup for some reason, the Managed Server starts in the ADMIN state instead of in the RUNNING state. The commonly used procedure in this situation is to click on the Resume button; the server instance resumes to the RUNNING state and starts accepting and processing the application requests.


But errors will occur with the applications that use this data source. Even if the database goes back online, the data source will not start automatically. Then you need to perform un-targeting and targeting of data source



(40) What will you do to avoid the ADMIN state on start-up when there is  a database issue?
To avoid the ADMIN state on start-up, set the data source Initial Capacity to 0 so it won't open any connection to the database  during the server startup process. The Managed Server instance will start in the RUNNING state, and as soon as the database  goes back online, the data source will reconnect to it without intervention.

(41) What is the use of Thin JDBC Driver?

Note:

• The Multi data source is responsible for managing the load and failover; so if the Oracle database uses the SCAN address feature, it's recommended to set up a Grid Link data source instead.
• In WebLogic Server 12c,  for production environments it would be to set Initial Capacity to 0 and Minimum Capacity and Maximum Capacity to the same value.
• During the WebLogic Server start up process, the data sources are deployed and the connections to the databases are opened according to the Initial Capacity parameter. 

WebLogic Deployment Modes

Weblogic Server provides three types of application deployment staging modes which determines how deployment files are made available to target servers that must deploy deployment files or deployment units (an application or stand-alone module.)

1. stage
2. nostage
3. external_stage

Most deployments use either stage or nostage modes and external_stage is least common deployment staging mode

Stage Mode Deployment

In stage mode, the Administration Server copies the deployment files or deployment source units from their original location on the Administration Server machine to the staging directories of each target server.

The staging directory is named "stage" by default, and it resides under the target server’s root directory. The target servers then deploy using their local copy of the deployment files.

For example, if you deploy a Java EE Application (ex:shoppingcart application) to two servers in a cluster using stage mode, the Administration Server copies the deployment files to directories on each of the two server machines. Each server then deploys the Java EE Application using its local copy of the archive files.

While copying deployment files, the Administration Server creates a sub-directory with the same name as the deployment name under the stage directory and copies the files.

The Administration Console uses stage mode as the default mode when deploying to more than one WebLogic Server instance. weblogic.Deployer uses the target server’s staging mode as the default, and Managed Servers use stage mode by default.

When to use Stage Mode Deployment:

• Stage mode ensures that each server has a local copy of the deployment files on hand, even if a network outage makes the Administration Server unreachable.

• If you are deploying small or moderate-sized applications to multiple WebLogic Server instances or Cluster

nostage mode deployment

In this mode, the Administration Server does not copy deployment unit files. Instead, all servers deploy using the same physical copy of the deployment files (from a shared or network-mounted directory), which must be directly accessible by the Administration Server and target servers.

The staging directory of target servers is ignored for nostage deployments.

By using Administration Console you can deploy the applications in nostage mode by selecting"I will make the deployment accessible from the following location". The Administration Console uses nostage mode as the default when deploying only to the Administration Server

When to use nostage Mode Deployment

• Deploying to a single-server domain

• Deploying applications to multiple targets or to a cluster where deployment files are available on a shared or network-mounted directory

• When you are deploying very large applications (large in size), consider nostage mode to avoid the overhead of copying large files to multiple servers

• Deploying exploded archive directories that you want to periodically redeploy after changing conten as in nostage mode, WebLogic Server copies out parts of the deployment to temporary directories. This enables users to update entire archived deployments or parts of archived deployments.

• In nostage mode, the Web application container automatically detects changes to JSPs and servlets. Nostage also allows you to later update only parts of an application by updating those parts in one file system location and then redeploying.

Note: Deploying very large applications in nostage mode saves time during deployment because no files are copied.

external_stage mode deployment

The Administration Server does not copy deployment files. Instead, the Administrator must ensure that deployment files are copied/distributed (manually or using automated scripts or thirdparty tools)
to the correct staging directory location before  deployment.  With external_stage deployments, the Administration Server requires a copy of the deployment files for validation purposes.

You can perform the copy manually or use automated scripts.

First you need to create a "stage" directory under target server’s root directory.
Create a sub-directory with the same name as the application deployment name under the above created stage directory
Copy the deployment source files in the above created sub-directory

When to use external stage Mode Deployment

• When you do not have a shared file system and if you you are deploying very large applications to multiple targets which are on different machines then using external stage is suggested as  it decreases the deployment time because files are not copied during deployment

• Deployments where you want to manually control the distribution of deployment files to target servers.

• Deploying to domains where third-party tools or scripts manage the copying of deployment files to the correct staging directories.

Analyzing Java Thread Dumps

Thread Dumps is an excellent mechanism to trouble shoot typical production issues. Analyzing Java Thread dumps will provide us the clear understanding of production issues. In this blog entry we will discuss about what is a thread dump, how to take the thread dump,when to take thread dump and how to analyze the thread dumps.
  
What is a thread?
A thread is a Light-Weight process. Java Threads are Light-Weight Processes of the JVM process. A WebLogic JVM process contains multiple threads

What is a thread dump?
A thread dump is a snapshot of all the Java threads that are currently running in a Java Virtual Machine (JVM) at a given point of time. A thread dump might contain single thread or multiple threads. Thread Dump will provide the stack traces of all the JVM threads and much more information about a particular thread what it is doing at that point of time.

When will you take thread dumps?

• Java application is running much slower than expected (poor response time)
• High CPU Utilization
• When Server/Application is hanging (server become unresponsive or not responding).

If you want to understand what is actively executed in the system during the load, you can take the thread dump and go through it.

How will you take the thread dumps?
There are several ways to take thread dumps

(1) Using jrcmd (jrockit 1.6)

 jrcmd <pid> print_threads (or)
 jrcmd <pid> print_threads nativestack=true jvmmonitors=true

The above two commands will print out the thread dump. It is possible to redirect the above thread dump to a file as below:

jrcmd <pid> print_threads nativestack=true jvmmonitors=true > /tmp/thread_dump.txt

Here <pid> is the java process id
nativestack=true will print C-level stacktraces as well as Java traces.
jvmmonitors=true will also print the JRockit JVM's internal native locks

Example:
/u01/app/oracle/product/fmw/jrockit_160_29_D1.2.0-10/bin/jrcmd  2789 print_threads nativestack=true jvmmonitors=true > /tmp/thread_dump_2789.txt

(2) Using jstack (Sun JDK) 

jstack <pid> (get the process id using jps -l)

You can redirect the output to a file as below
jstack <pid> > threaddump.log

When Java process is hung or not responding, you can take the thread dump as below:
jstack  -F -l <pid> (or)
jstack  -F -l <pid> > threaddump.log

Options:
    -F  to force a thread dump. Use when jstack <pid> does not respond (process is hung)
    -l  long listing. Prints additional information about locks

(3) Using WebLogic Admin Console
Login to Admin Console
Click on Servers under domain tree > Click on the Server (for which you want to take thread dump) >  Monitoring > Threads  >Click on "Dump Thread Stack" Button. This will generate Thread dump in the Admin Console



(4) Using kill command in Unix/Linux
kill -3 <pid> (get the  process id using ps -ef | grep "java")

(5) Using weblogic.Admin utility (deprecated, still you can use)
You can take the thread dump for  WebLogic Admin java process using below comamnd:
 java weblogic.Admin -url t3://<Admin Server Host Name>:<Admin ServerPort> -username <weblogic admin username> --password <weblogic admin passord> THREAD_DUMP

For WebLogic managed servers you can take thread dump as below:
 java weblogic.Admin -url t3://<Managed Server Host Name>:<Managed ServerPort> -username <weblogic admin username> --password <weblogic admin passord> THREAD_DUMP

Note: The THREAD_DUMPS will be generated in the Servers STDOUT file.

Eg: 
To take thread dump of AdminServer running on AdminHost with the port 8001
java weblogic.Admin -url t3://AdminHost:8001 -username weblogic -password weblogic THREAD_DUMP

To take thread dump of managed server running MngHost on localhost with the port 8003
java weblogic.Admin -url t3://MngHost:8001 -username weblogic -password weblogic THREAD_DUMP

(6) Using WLST
In WLST threadDump command displays a thread dump for the specified server.

Syntax:
threadDump([writeToFile], [fileName], [serverName])
   
writeToFile: This argument defaults to true, indicating that output is saved to a file.
fileName: Name of the file to which the output is written. It is pptional.
serverName:This argument defaults to the server to which WLST is connected.   It is optional. If you don't specify the serverName it displays the thread dump for connected server

Example:
You can follow the below steps to take the thread dump.

$ pwd
/u01/app/oracle/product/fmw/wlserver_10.3/common/bin
$ ./wlst.sh
wls:/offline> connect('weblogic','weblogic','t3://localhost:7001')
Connecting to t3://localhost:7001 with userid weblogic ...
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'test_domain'.

Warning: An insecure protocol was used to connect to the
server. To ensure on-the-wire security, the SSL port or
Admin port should be used instead.

wls:/test_domain/serverConfig> threadDump()
Thread dump for the running server: AdminServer

===== FULL THREAD DUMP ===============
Sat May 31 11:23:50 2014
Oracle JRockit(R) R28.2.4-14-151097-1.6.0_33-20120618-1634-linux-x86_64

"Main Thread" id=1 idx=0x4 tid=2487 prio=5 alive, waiting, native_blocked
    -- Waiting for notification on: weblogic/t3/srvr/T3Srvr@0xf18a00b8[fat lock]
    at jrockit/vm/Threads.waitForNotifySignal(JLjava/lang/Object;)Z(Native Method)
    at java/lang/Object.wait(J)V(Native Method)
    at java/lang/Object.wait(Object.java:485)
    at weblogic/t3/srvr/T3Srvr.waitForDeath(T3Srvr.java:981)
    ^-- Lock released while waiting: weblogic/t3/srvr/T3Srvr@0xf18a00b8[fat lock]
    at weblogic/t3/srvr/T3Srvr.run(T3Srvr.java:490)
    at weblogic/Server.main(Server.java:71)
    at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)
    -- end of trace

........

........

........

===== END OF THREAD DUMP ===============

The Thread Dump for server AdminServer
has been successfully written to Thread_Dump_AdminServer.txt
wls:/test_domain/serverConfig>

 $ [mastshai@OEL bin]$ ls Thread_Dump_AdminServer.txt
Thread_Dump_AdminServer.txt

You can also write a python script to generate thread dump as below:

$ cat ThreadDump.py
connect('weblogic','weblogic','t3://localhost:7001')
cd('Servers')
cd('AdminServer')
threadDump(writeToFile='true',fileName='ThreadDump.txt')
disconnect()
exit()

Now run setWLSEnv.sh script to setup the classpath & path

/u01/app/oracle/product/fmw/wlserver_10.3/server/bin
$ . ./setWLSEnv.sh

Finally run the below command to generate the thread dump using WLST

$ java weblogic.WLST  ThreadDump.py 

What are different thread states?
For analyzing thread dumps, you need to know the status of threads. The statuses of threads are
NEW: The thread is created but not available to process the requests.

RUNNABLE (ACTIVE): The thread is either currently processing the request or ready to run when it gets its CPU. It may be in WAITING status due to the OS's resource distribution. JRockit thread dumps refer to this state as ACTIVE.

BLOCKED or Locked (MW): Waiting for Monitor Entry - The thread is waiting to get the lock( a different thread may be holding the lock)

WAITING or Waiting on Monitor or CW: The thread is waiting by using a wait, join or park method.  For example, In WebLogc server the idle execute threads are in this condition and they wait till a socket reader thread notify them of some new work to be done.


What are the different types of WebLogic thread states?

Weblogic administrators need to understand different thread states and monitoring WebLogic threads.

• Active Execute Threads
• Idle Execute Threads
• Standby Threads
• Hogging Threads
• Stuck Threads

The thread monitoring section can be accessed for Admin and each managed server Managed server under the Monitoring > Threads tab.

 

From the above you can see, the thread monitoring tab provides a complete view of each WebLogic thread along with its state. Now we can try to understand WebLogic thread states.

Active Execute Threads: The threads which are currently processing the requests or ready to process the requests(idle threads). When thread demand goes up, WebLogic will start promoting threads from Standby to Active state which will enable them to process future client requests.

Execute Thread Idle Count: This is the number of Active idle threads currently “available” to process a client request.

Standby Thread Count: This is the number of threads waiting to be marked “eligible” to process client requests. These threads are created and visible from the JVM Thread Dump but not available yet to process a client request.

Execute Thread Total Count: This is the total number of threads “created” from the Weblogic self-tuning pool and visible from the JVM Thread Dump.You can calcualte these threads as below.

 Execute Thread Total Count = Active Execute Threads + Standby Threads

Hogging Thread Count: This is the number of threads taking much more time to process the request than the average current execution time.

Stuck Threads: The threads which are taking more time to process the request than the configured stuck thread time.  When facing slowdown conditions,  the WebLogic threads transition from the Hogging state to Stuck stage, depending how long these threads remain stuck executing their current request.

In WebLogic Admin console you can configure Stuck thread related parameters for Admin and each  Managed server under the Configuration > Tuning tab.

Stuck Thread Max Time:The number of seconds that a thread must be continually working before this server considers the thread stuck. The default value is 600 seconds(10mins)

Stuck Thread Timer Interval:The number of seconds after which WebLogic Server periodically scans threads to see if they have been continually working for the configured maximum length of time. The default value is 60 seconds