There are mainly to approaches to solve such problems:
1. Optimistic locking (Optimistic concurrency control)
2. Pessimistic locking
Quote:
How should I write my app to manage with that kind of problems ?
If you choose for Optimistic locking (most popular approach in hibernate), then your app should catch the org.hibernate.StaleStateException,
rollback the transaction, if it still active and inform the user that a concurrency conflict happened,
and that he has to redo the transaction from scratch with updated situation.
The appplication should manage the StaleStateException in a way that the user can redo his work without to much effort.
If you choose for Pessimistic locking, the your appplication must try to lock each Book instance before editing it.
If the lock action fails (because concerning book is already locked by another user), then your app should handle this by
advicing the user that concerning book is currently locked by another user.
N.B.: In this Pessimistic locking context it is of interest to establish whether your hibernate.dialect supports lock LockMode.UPGRADE_NOWAIT or not. If NOWAIT option is not properly supported, you have to wait until the other user releases the lock.
If the other user interacts with a GUI-interface, it could take long time until he terminates the transaction.
Find more informations about here
http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/transactions.html#transactions-optimistic