WebSphere eXtreme Scale Administration Guide > Troubleshoot

Troubleshoot loaders

Use this information to troubleshoot issues with the database loaders.

Procedure

• 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:

  BackMap 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" />
  

Parent topic

Troubleshoot

Related concepts

Loaders

Loader configuration

Loaders overview

Related tasks

Configure JPA loaders

Configure a JPA time-based data updater

Related reference

Write-behind dumper class sample code

+

Search Tips   |   Advanced Search