When a database server reboots or a network failure has occurred, all connections in the database connection pool are broken. To overcome this issue, JIRA would normally need restarting (or for JIRA WAR distributions, the application server running JIRA would need restarting).
However, database connections in the database connection pool can be validated by running a simple SQL query. If a broken database connection is detected in the pool, a new one is created to replace it.
To do this, you need to specify an optional
<validation-query/> element (in the
dbconfig.xml file of your JIRA Home Directory), whose content is the query which validates connections in the database connection pool. See the following procedure for details.
Ensuring JIRA validates connections to its database
To ensure JIRA validates database connections in the database connection pool:
- Shut down JIRA (or the Tomcat installation running JIRA).
- Edit the
dbconfig.xmlfile at the root of your JIRA Home Directory or use the Advanced tab of the JIRA Configuration Tool to configure the relevant settings.
- Configure the validation query for your type of database:
If editing the
dbconfig.xmlfile, add the
<validation-query/>element with the appropriate validation query for your type of database, as shown in the example below for MySQL. (See Determining the Validation Query below for details.)
- If using the JIRA Configuration Tool, on the Advanced tab, select the Validation Query check box and enter the appropriate validation query for your type of database. (See Determining the Validation Query below for details.)
- Specify a validation query timeout for your validation query, whose value is the appropriate length of time (in seconds) that the system should wait for a validation query to succeed before the system considers the database connection broken:
- If editing the
dbconfig.xmlfile, add the
<validation-query-timeout/>element with the appropriate length of time (in seconds). This should only be done for MySQL.
- If using the JIRA Configuration Tool, on the Advanced tab, select the Validation Query Timeout check box and enter the appropriate length of time (in seconds).
- If editing the
You may wish to specify the following options, which relate to the above validation query options (see Tuning Database Connections - Connection pool settings section for details):
JIRA Configuration Tool 'Advanced' tab option
Test While Idle
Time Between Eviction Runs
Minimum Evictable Idle Time
Save your edited
dbconfig.xmlfile (or click the Save button if using the JIRA Configuration Tool).
- Restart JIRA (or the Tomcat installation running JIRA).
Please Note: If you continue to have problems with connections closing, you may need to set the
time-between-eviction-runs-millis parameter to a lower value or as a last resort, set
true. For more information about
test-on-borrow, see Tuning Database Connections - Connection pool settings section.
Determining the Validation Query and Timeout
Different database types have slightly different SQL syntax requirements for their validation query. The validation query should be as simple as possible, as this is run every time a connection is retrieved from the pool. The validation query timeout should only be set for MySQL.
The following validation queries are recommended for the following types of databases:
|Validation Query Timeout|
Microsoft SQL Server
If the Validation Query Timeout is used on any database other than MySQL it will cause significant problems with the JIRA instance.
You should now be able to recover from a complete loss of all connections in the database connection pool without the need to restart JIRA or the application server running JIRA.
- Setting this option has a performance impact. The overall decrease in performance should be minimal, as the query itself is quick to run. In addition, the query will only execute when you make a connection. Thus, if the connection is kept for the duration of a request, the query will only occur once per request.
- If you are running a large JIRA installation, you may wish to assess the performance impact of this change before implementing it.