Example: Handling data access exception - error mapping in DataStoreHelper


 

+

Search Tips   |   Advanced Search

 

WAS v7.0 provides a DataStoreHelper interface for mapping different database SQL error codes to the appropriate exceptions in the appserver.

Error mapping is necessary because various database vendors can provide different SQL errors and codes that represent that same issue. For example, the stale connection exception has different codes in different databases.

The DB2 SQLCODEs of 1015, 1034, 1036 , and so on indicate that the connection is no longer available because of a temporary database problem. The Oracle SQLCODEs of 28, 3113, 3114, and so on indicate the same situation.

Mapping these error codes to standard exceptions provides the consistency that makes applications portable across different installations of the appserver.

The following code segment illustrates how to add two error codes into the error map:

 public class NewDSHelper extends GenericDataStoreHelper
{
  public NewDSHelper(java.util.Properties dataStoreHelperProperties)  
  {
    super(dataStoreHelperProperties);
    java.util.Hashtable myErrorMap = null;
    myErrorMap = new java.util.Hashtable();
    myErrorMap.put(new Integer(-803), myDuplicateKeyException.class);
    myErrorMap.put(new Integer(-1015), myStaleConnectionException.class);
    myErrorMap.put("S1000", MyTableNotFoundException.class);
    setUserDefinedMap(myErrorMap);
    ...
  }
}

New feature: V7.0 includes a new custom property for the data sources called userDefinedErrorMap, which overlays existing entries in the error map by invoking the method...

DataStoreHelper.setUserDefinedMap

The userDefinedErrorMap can be used to add, change, or remove entries from the error map.

For example, to...

...select the data source and configure the custom properties with...

"S1000"=;1062=com.ibm.websphere.ce.cm.DuplicateKeyException;"08004"= com.ibm.websphere.ce.cm.StaleConnectionException

A configuration option referred to as the Error Detection Model controls how the error map is used. At V6 and earlier, Exception Mapping was the only option available for the Error Detection Model. At V7 and later, another option called Exception Checking is also available.

Under the Exception Mapping model, the appserver consults the error map and replaces exceptions with the corresponding exception type listed in the error map. Under the Exception Checking model, the appserver still consults the error map for its own purposes but does not replace exceptions. If we wish to continue to use Exception Mapping, you do not need to change anything. Exception Mapping is the default Error Detection Model.



Related concepts

Exceptions pertaining to data access

 

Related tasks

Change the error detection model to use the Exception Checking Model