Database generated version ID with WSJPA
Java™ Persistence API for WebSphere® Application Server (WSJPA) 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 WebSphere Application
Server supports. Support is based on two Version Strategies in JPA
for WebSphere Application
Server.
- @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
The Entity class is defined with the new Version Strategy annotation.
The Entity has a surrogate version column. For example,
@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 is as follows: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 VersionColumn
value is updated in the database. After the update, the value for
VersionColumn 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 Version ID 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 is updated in the database. After the update, the value for Version is retrieved from the database and updated in the in memory object. Thereby the objects in the data cache reflect the correct 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;
}

- For z/OS® DB2® V9 and Linux, UNIX, and Windows DB2 V9.5, the generated database column must be of type timestamp, but both the RowChangeTimestampStrategy and the RowChangeVersionStrategy are supported. Microsoft SQL Server only supports a non-timestamp generated version ID that goes with the RowChangeVersionStrategy. To use the RowChangeTimestampStrategy, you must use a trigger on a timestamp field in the database. For other databases, you 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 you have installed the required level of IBM® Optim™ PureQuery Runtime (1.3.100 or later) and JCC drivers (3.52.95 or later).