The optional <timestamp> element indicates that the table contains timestamped data. This is intended as an alternative to versioning. Timestamps are by nature a less safe implementation of optimistic locking. However, sometimes the application might use the timestamps in other ways.

<timestamp
        column="timestamp_column"
        name="propertyName"
        access="field|property|ClassName"
        unsaved-value="null|undefined"
        source="vm|db"
        generated="never|always"
        node="element-name|@attribute-name|element/@attribute|."
/>

column (optional - defaults to the property name): The name of a column holding the timestamp.

name: The name of a JavaBeans style property of Java type Date or Timestamp of the persistent class.

access (optional - defaults to property): The strategy Hibernate should use for accessing the property value.

unsaved-value (optional - defaults to null): A version property value that indicates that an instance is newly instantiated (unsaved), distinguishing it from detached instances that were saved or loaded in a previous session. (undefined specifies that the identifier property value should be used.)

source (optional - defaults to vm): From where should Hibernate retrieve the timestamp value? From the database, or from the current JVM? Database-based timestamps incur an overhead because Hibernate must hit the database in order to determine the "next value", but will be safer for use in clustered environments. Note also, that not all Dialect s are known to support retrieving of the database's current timestamp, while others might be unsafe for usage in locking due to lack of precision (Oracle 8 for example).

generated (optional - defaults to never): Specifies that this timestamp property value is actually generated by the database. See the discussion of Section 5.6, “Generated Properties” generated properties.

Note that <timestamp> is equivalent to <version type="timestamp">. And <timestamp source="db"> is equivalent to <version type="dbtimestamp">