Best type for JPA version field for Optimistic locking -

i have doubts best type field annotated @version optimistic locking in jpa.

the api javadoc (http://docs.oracle.com/javaee/7/api/javax/persistence/version.html) says:

"the following types supported version properties: int, integer, short, short, long, long, java.sql.timestamp."

in other page (http://en.wikibooks.org/wiki/java_persistence/locking#optimistic_locking) says:

"jpa supports using optimistic locking version field gets updated on each update. field can either numeric or timestamp value. numeric value recommended numeric value more precise, portable, performant , easier deal timestamp."

"timestamp locking used if table has last updated timestamp column, , convenient way auto update last updated column. timestamp version value can more useful numeric version, includes relevant information on when object last updated."

the questions have are:

• is better timestamp type if going have lastupdated field or better have numeric version field , timestamp in other field?

• between numeric types (int, integer, short, short, long, long) best choose (considering length of each type)? mean, think best long requires lot of space each row.

• what happens when version field gets last number of numeric type (for example 32,767 in short field)? start 1 again in next increment?

first, know locking used managed concurrent transactions.

1.separate concerns. if lastupdated field business model specific, should separate versioning field - - versioning.

2.primitives , objects mapped db same type. except fact boolean default nullable , boolean 'not nullable'. however, enforce nullability explicitly. in case want use primitive version field can't nullable.

integer or long better timestamp. hibernate recommends numeric versionig , don't take space.

3. if use long, might not live find out.

use , should fine.

private long version;  @version public long getversion() {     return version; }  public void setversion(long version) {     this.version = version; }