Miglior tipo per campo versione JPA per blocco ottimistico

Question

Ho dei dubbi su quale sia il tipo migliore per un campo annotato con @Version per il blocco ottimistico in JPA.

Javadoc API (http://docs.oracle.com/javaee/7/api/javax/persistence/Version.html) dice:

"I seguenti tipi sono supportati per le proprietà di versione: Int., Integer, breve, breve, lunga, lunga, java.sql.Timestamp"

In altra pagina (http://en.wikibooks.org/wiki/Java_Persistence/Locking#Optimistic_Locking) dice:..

"APP sostiene utilizzando una versione campo blocco ottimistico che viene aggiornato ad ogni aggiornamento Il campo può essere sia numerico o un valore timestamp Un valore numerico è raccomandato come un il valore numerico è più preciso, portatile, performante e più facile da gestire rispetto a un timestamp ".

"bloccaggio Timestamp viene frequentemente utilizzato se la tabella contiene già una ultima colonna timestamp aggiornamento, ed è anche un modo conveniente per l'aggiornamento automatico last colonna aggiornata. Il valore versione timestamp può essere più utile di una versione numerico, poiché include le informazioni rilevanti su quando l'oggetto è stato aggiornato l'ultima volta. "

Le domande che ho sono:

• è meglio un tipo Timestamp se avete intenzione di avere un campo lastUpdated o è meglio avere un campo versione numerica e il timestamp in altri campi?

• Tra tipi numerici (int, intero, breve, corto, lungo, lungo) che è il migliore da scegliere (considerando la lunghezza di ciascun tipo)? Voglio dire, penso che il meglio sia Long ma richiede molto spazio per ogni riga.

• Cosa succede quando il campo versione raggiunge l'ultimo numero di un tipo numerico (ad esempio 32.767 in un campo breve)? Ricomincerà da 1 nel prossimo incremento?

Answer 1

Innanzitutto, sapere che il blocco viene utilizzato per le transazioni concorrenti gestite.

1.Separate le vostre preoccupazioni. Se il campo aggiornato è specifico del modello di business, dovrebbe essere separato dal campo di controllo delle versioni, che è per il - versioning.

2. I valori e gli oggetti vengono generalmente associati al db come lo stesso tipo. Tranne il fatto che Boolean di default sarà annullabile e booleano sarà 'non annullabile'. Tuttavia, applicare il nullable in modo esplicito. In questo caso, si desidera utilizzare una primitiva in quanto il campo della versione non può essere annullabile.

Integer o long sono migliori di timestamp. Hibernate recommends numeric versionig e non occupano molto spazio.

3. Se si utilizza molto tempo, potrebbe non vivere per scoprirlo.

Utilizzare questo e si dovrebbe andare bene.

private long version; 

@Version 
public long getVersion() { 
    return version; 
} 

public void setVersion(long version) { 
    this.version = version; 
} 

Answer 2

Basta andare con Long o Integer. MA non andare con int o long. Al contrario di altri commenti qui, è previsto un valore nullo quando l'entità non è mai stata ancora mantenuta. Avere int o long potrebbe rendere Hibernate in grado di pensare che l'entità sia già persistente e in stato di distacco poiché il valore della versione sarà 0 quando non impostato. Appena terminato il debug di una violazione FK dove "int" era la causa, risparmia il tuo tempo e vai con Long o Integer.