Using Version Locking Policies

For each of the following version locking policies, you must add a specific database field.

For VersionLockingPolicy, add a numeric field.
For TimestampLockingPolicy, add a timestamp field.

TopLink records the version as it reads an object from a table. When the client attempts to write the object, TopLink compares the version of the object with the version in the table record.

If the versions are the same, the updated object is written to the table, and the version of both the table record and the object are updated.
If the versions are different, the write is disallowed because another client must have updated the object since this client initially read it.

The two version locking policies have different ways of writing to the database:

For VersionLockingPolicy, the number in the version field increments by one.
For TimestampLockingPolicy, a new timestamp is inserted into the row (this policy can be configured to get the time from the server or locally).

For both policies, the values of the write lock field can be the writable mapping within the object.

If the value is stored in the identity map, then by default an attribute mapping is not required for the version field. If the application does map the field, it must make the mappings read-only to allow TopLink to control writing the fields.