JPA and Hibernate: @Version for optimistic locking

What are the possible strategies to handle multiple updates of the same record at the same time?

1. Do Nothing

2. Lock the entire record (pessimistic locking)

3. Optimistic Locking:

Optimistic locking does not use exclusive locks when reading. Instead, a check is made during the update to make sure that the record has not been changed since it was read.  It's often implemented through a single column (of type Timestamp, or Number), used for no other purpose than implementing optimistic concurrency. this column is given a value when the row is inserted. Whenever the record is read, the timestamp column is read as well. When an update is performed, the timestamp column is checked: if it has the same value at UPDATE time as it had when it was read, then the UPDATE is performed and the timestamp is updated as well. If the timestamp value is different at UPDATE time, then an error is returned to the user: they must re-read the record, re-make their changes, and try to update the record again.

CRUD generico con Java Reflection API, EclipseLink ed ICEFaces

Problema: abbiamo un nutrito insieme di tabelle anagrafiche con struttura simile (solitamente ID, DESCRIZIONE e pochi altri campi), e vorremmo offirire nella nostra applicazione Web le funzionalità CRUD su di esse. Quello che vogliamo assolutamente evitare è la replicazione del codice che offre queste funzionalità per ogni tabella da gestire: in sostanza, si desidera un approccio quanto più generico possibile al problema.

Voglio condividere con voi una soluzione a questo problema a mio avviso molto interessante, che fa uso estensivo delle Reflection API di Java, EJB 3.0, JPA (con EclipseLink 1.20 come persistence engine) per il backend, e IceFaces 1.8 per la parte grafica.