Configuring Datasource Fatal Error Codes

There
are well known error codes on JDBC operations that can always be interpreted as
the database shutting down, already down, or a configuration problem.  In this case, we don’t want to keep the
connection around because we know that subsequent operations will fail and they
might hang or take a long time to complete. These error codes can be
configured in the datasource configuration using the “fatal-error-codes”
value on the Connection Pool Parameters. The value is a comma separated list of error codes.  If
a SQLException is seen on a JDBC operation and sqlException.getErrorCode()
matches one of the configured codes, the connection will be closed instead of
returning it to the connection pool.

Note that in the earlier OC4J application
server, it closed all connections in the pool when one of these errors occurred
on any connection. In the WLS implementation, we chose to only close the
connection that got the fatal error.  This allows you to add some error codes that are specific to a connection going bad in addition to the database being unavailable.

The following error codes are pre-configured and
cannot be disabled. You can provide additional
error codes for these or other drivers on individual datasources.

The following is a WLST script to add a fatal error
code string to an existing datasource.

# java weblogic.WLST fatalerrorcodes.py

import sys, socket, os

hostname = socket.gethostname()

datasource=”JDBC GridLink Data Source-0″

connect(“weblogic”,”welcome1″,”t3://”+hostname+”:7001″)

edit()

startEdit()

cd(“/JDBCSystemResources/” + datasource )

targets=get(“Targets”)

set(“Targets”,jarray.array([], ObjectName))

save()

activate()

startEdit()

cd(“/JDBCSystemResources/” + datasource + “/JDBCResource/”
+
datasource +
“/JDBCConnectionPoolParams/” + datasource )

set(“FatalErrorCodes”,”1111,2222″)

save()

activate()

startEdit()

cd(“/JDBCSystemResources/” + datasource )

set(“Targets”, targets)

save()

activate()

As an experiment, I tried this with REST.

localhost=localhost

editurl=http://${localhost}:7001/management/weblogic/latest/edit

name=”JDBC%20GridLink%20Data%20Source%2D0″


curl -v \

–user weblogic:welcome1 \

-H X-Requested-By:MyClient \

-H Accept:application/json \

-X GET \

${editurl}/JDBCSystemResources/${name}/JDBCResource/JDBCConnectionPoolParams?links=none”

curl -v \

–user weblogic:welcome1 \

-H X-Requested-By:MyClient \

-H Accept:application/json \

-H Content-Type:application/json \

-d “{}” \

-X POST “${editurl}/changeManager/startEdit”

curl -v \

–user weblogic:welcome1 \

-H X-Requested-By:MyClient \

-H Accept:application/json \

-H Content-Type:application/json \

-d “{
targets: []

}” \

-X POST “${editurl}/JDBCSystemResources/${name}”

curl -v \

–user weblogic:welcome1 \

-H X-Requested-By:MyClient \

-H Accept:application/json \

-H Content-Type:application/json \

-d “{
fatalErrorCodes: ‘1111,2222’

}” \

-X POST \

“${editurl}/JDBCSystemResources/${name}/JDBCResource/JDBCConnectionPoolParams”

curl -v \

–user weblogic:welcome1 \

-H X-Requested-By:MyClient \

-H Accept:application/json \

-H Content-Type:application/json \

-d “{
targets: [ { identity: [ servers,
‘myserver’ ] } ]

}” \

-X POST “${editurl}/JDBCSystemResources/${name}”

curl -v \

–user weblogic:welcome1 \

-H X-Requested-By:MyClient \

-H Accept:application/json \

-H Content-Type:application/json \

-d “{}” \

-X POST “${editurl}/changeManager/activate”

curl -v \

–user weblogic:welcome1 \

-H X-Requested-By:MyClient \

-H Accept:application/json \

-X GET “${editurl}/JDBCSystemResources/${name}?links=none”