Configuring OCC options

None

If you specify no timestamp or lock-related attributes in the <persistentObject> configuration, the default behavior is OCC with all-values comparison for version control.

timestampColumn

Applies only to <persistenObject>

Set the timestampColumn attribute in the <persistentObject> configuration to specify the name of a column that holds a row timestamp which is automatically set (or changed) by the database server whenever a row is inserted (or updated). This column is usually the database timestamp type – you can use the timestamp datatype if using Sybase Adaptive Server Enterprise or Adaptive Server Anywhere version 7.0 or later.

versionColumn

Applies only to <persistenObject>

Set the versionColumn attribute in the <persistentObject> configuration to specify the name of an integer-typed column that holds a row version which is automatically set (or changed) by the persistence manager whenever a row is inserted (or updated).

If, due to triggers or other database-specific mechanisms, this version column is also updated when ad-hoc updates are made to the database table by a client which is not performing version management, then the trigger or other mechanism must be disabled when the persistence manager is in use. This disabling is needed to prevent an update issued by the persistence manager resulting in a double increment of the version column (one time by the persistence manager and one time by the database server). To disable triggers, set the Disable Triggers property for the data source.

tableVersion

Set the tableVersion attribute in the <persistentObject> or <queryMethod> configuration to specify the use of a timestamp table.

Specify a table and column name, in the form ts_table.ts_column, where ts_table specifies the timestamp table and ts_column specifies the name of the timestamp column in the timestamp table. The specified timestamp table must be separate from the main table. The timestamp tables can contain multiple columns, to allow use of one timestamp table by multiple entity beans. Timestamp tables are automatically created if they do not exist.

A timestamp table can be shared among multiple components even when only one column is present in the timestamp table. In other words, a single timestamp value can be shared by multiple tables. This helps further improve performance for a group of read-mostly tables. However, any insert, delete, or update on any of the tables results in all cache entries being discarded.

If, due to triggers or other database-specific mechanisms, this “table version” column is also updated when ad-hoc updates are made to the database table by a client which is not performing version management, then the trigger or other mechanism must be disabled when the persistence manager is in use. This disabling is needed to prevent an update issued by the persistence manager resulting in a double increment of the table version column (one time by the persistence manager and one time by the database server). To disable triggers, set the Disable Triggers property for the data source.

You cannot use a timestamp table if external processes outside of EAServer can update the versioned data without updating the timestamp table.

parentVersion

Set the parentVersion attribute in the <persistentObject> or <queryMethod> configuration to specify version control using a particular version of a “parent” object to allows cached entities to be associated with a particular version of a “parent” object, while guaranteeing a high level of transactional consistency. The syntax of this property is:

ParentEntity[ForeignKey].version

The parent entity refers to another entity which uses the versionColumn attribute as the timestamp mechanism. The foreign key is a persistent field of the current entity which is assumed to be the primary key for the corresponding parent object. This is particularly useful in combination with a logical isolation level of RepeatableReadWithCache or SerializableWithCache.

As an example, a foreign key field custId declared on an Order entity could be associated with a parent Customer entity by using the parent version expression:

Customer[custId].version