Troubleshooting loaders

Use this information to troubleshoot issues with your database loaders.

• Problem: The loader is unable to communicate with the database. A LoaderNotAvailableException exception occurs.

  Explanation: The loader plug-in can fail when it is unable to communicate to the database back end. This failure can happen if the database server or the network connection is down. The write-behind loader queues the updates and tries to push the data changes to the loader periodically. The loader must notify the ObjectGrid run time that there is a database connectivity problem by throwing a LoaderNotAvailableException exception.

  Solution: The Loader implementation must be able to distinguish a data failure or a physical loader failure. Data failure should be thrown or rethrown as a LoaderException or an OptimisticCollisionException, but a physical loader failure must be thrown or rethrown as a LoaderNotAvailableException. ObjectGrid handles these two exceptions differently:

  • If a LoaderException is caught by the write-behind loader, the write-behind loader considers the exception a failure, such as duplicate key failure. The write-behind loader unbatches the update, and tries the update one record at one time to isolate the data failure. If A {{LoaderException}}is caught again during the one record update, a failed update record is created and logged in the failed update map.
  • If a LoaderNotAvailableException is caught by the write-behind loader, the write-behind loader considers it failed because it cannot connect to the database end, for example, the database back-end is down, a database connection is not available, or the network is down. The write-behind loader waits for 15 seconds and then try the batch update to the database again.

  The common mistake is to throw a LoaderException while a LoaderNotAvailableException must be thrown. All the records queued in the write-behind loader become failed update records, which defeats the purpose of back-end failure isolation.
• Problem: When you are using an OpenJPA loader with DB2® in WebSphere® Application Server, a closed cursor exception occurs.
  The following exception is from DB2 in the org.apache.openjpa.persistence.PersistenceException log file:

  [jcc][t4][10120][10898][3.57.82] Invalid operation: result set is closed.

  Solution: By default, the application server configures the resultSetHoldability custom property with a value of 2 (CLOSE_CURSORS_AT_COMMIT). This property causes DB2 to close its resultSet/cursor at transaction boundaries. To remove the exception, change the value of the custom property to 1 (HOLD_CURSORS_OVER_COMMIT). Set the resultSetHoldability custom property on the following path in the WebSphere Application Server cell: Resources > JDBC provider > DB2 Universal JDBC Driver Provider > DataSources > data_source_name > Custom properties > New.

• Problem DB2 displays an exception: The current transaction has been rolled back because of a deadlock or timeout. Reason code "2".. SQLCODE=-911, SQLSTATE=40001, DRIVER=3.50.152

  This exception occurs because of a lock contention problem when you are running with OpenJPA with DB2 in WebSphere Application Server. The default isolation level for WebSphere Application Server is Repeatable Read (RR), which obtains long-lived locks with DB2.

  Solution:

  Set the isolation level to Read Committed to reduce the lock contention. Set the webSphereDefaultIsolationLevel data source custom property to set the isolation level to 2(TRANSACTION_READ_COMMITTED) on the following path in the WebSphere Application Server cell: Resources > JDBC provider > JDBC_provider > Data sources > data_source_name > Custom properties > New. For more information about the webSphereDefaultIsolationLevel custom property and transaction isolation levels, see Requirements for setting data access isolation levels.

• Problem: When you are using the preload function of the JPALoader or JPAEntityLoader, the following CWOBJ1511 message does not display for the partition in a container server: CWOBJ1511I: GRID_NAME:MAPSET_NAME:PARTITION_ID (primary) is open for business.

  Instead, a TargetNotAvailableException exception occurs in the container server, which activates the partition that is specified by the preloadPartition property.

  Solution: Set the preloadMode attribute to true if you use a JPALoader or JPAEntityLoader to preload data into the map. If the preloadPartition property of the JPALoader and JPAEntityLoader is set to a value between 0 and total_number_of_partitions - 1, then the JPALoader and JPAEntityLoader try to preload the data from backend database into the map. The following snippet of code illustrates how the preloadMode attribute is set to enable asynchronous preload:

  BackingMap bm = og.defineMap( "map1" ); 
  bm.setPreloadMode( true );

  You can also set the preloadMode attribute by using an XML file as illustrated in the following example:

   <backingMap name="map1" preloadMode="true" pluginCollectionRef="map1"   
  		lockStrategy="OPTIMISTIC" />