Database generated version ID

Java Persistence API (JPA) for WAS has extended OpenJPA to work with database generated version IDs. These generated version fields (timestamp or token) can be used to efficiently detect changes to a given row.

Trigger based version ID generation is supported for all databases that WAS supports. Support is based on two VStrategies in JPA for WAS.

• @VersionStrategy("com.ibm.websphere.persistence.RowChangeTimestampStrategy"), if the entity version field type is Timestamp, and

• @VersionStrategy("com.ibm.websphere.persistence.RowChangeVersionStrategy"), if the entity version field type is Long

Database generated version ID example

In this example, the Entity class is defined with the new VStrategy annotation. The Entity has a surrogate version column.

@Entity(name="Item")
@VersionColumn(name="versionField")
@VersionStrategy("com.ibm.websphere.persistence.RowChangeTimestampStrategy") public class Item implements Serializable
{  
  @Id
  private int id2;
  
  private String name;
  
  private double price;

   @OneToOne
   private Owner master;
}

The create table statement for this would be:

CREATE TABLE ITEM (ID2  INT  NOT NULL,  NAME  VARCHAR(50) ,  PRICE   DOUBLE,  OWNER_ID INT,              VERSIONFIELD GENERATED ALWAYS FOR EACH ROW ON 
              UPDATE AS ROW CHANGE TIMESTAMP
                  PRIMARYKEY(ID2));

During any updates to Item (insert or update) the VColumn value will be updated in the database. After the update, the value for VColumn is retrieved from the database and updated in the in memory object. Thereby the objects in the data cache reflect the correct version value. Here the Entity is using the @VersionColumn which produces a Surrogate VId rather than defining an explicit field in the entity .

The Entity could also use @Version annotation to define an explicit version field. The explicit version field could be of type Long or Timestamp corresponding to the @VersionStrategy. During any updates to Item (insert or update) the Version value will be updated in the database. After the update the value for Vwould be retrieved from the database and updated in the in memory object. Thereby the objects in the data cache would reflect the right version value.

This is an example where the Entity has a version field defined, and the type Timestamp matches the RowChangeTimestampStrategy in the @VersionStrategy (if the version field type is using type long, then the RowChangeVersionStrategy should be annotated to match) :

@Entity(name="Item")
@VersionStrategy("com.ibm.websphere.persistence.RowChangeTimestampStrategy") public class Item implements Serializable
  
{
  @Id
  private int id2;
  
  private String name;
  
  private double price;
   
   @Version
   private Timestamp versionField;

   @OneToOne
   private Owner master;
}

Avoid trouble: Be aware of the following conditions when you use RowChangeVersionStrategy:

• For z/OS DB2 V9 and Linux, Unix, and Windows DB2 V9.5, the generated database column must be of type timestamp but we support both the RowChangeTimestampStrategy and the RowChangeVersionStrategy. MS SqlServer only supports a non timestamp generated version ID that goes with the RowChangeVersionStrategy . To use the RowChangeTimestampStrategy, use a trigger on a timestamp field in the database. For other databases we can use triggers to simulate database version generation and use either strategy.

• For z/OS DB2 V9, install the PTF for APAR PK67706, and ensure that we have installed the required level of PureQuery (1.3.100 or later) and JCC drivers (3.52.95 or later).

---

 

Related tasks

Associating persistence units and data sources