On October 23rd, 2014, we updated our
By continuing to use LinkedIn’s SlideShare service, you agree to the revised terms, so please take a few minutes to review them.
Hibernate 3.x exceptions are typed runtime exceptions.
HibernateException – generic exception.
JDBCException – thrown by hibernate internal JDBC layer. Subtypes –
Hibernate typed exceptions
All exceptions throws by Hibernate are RuntimeException and are fatal exceptions. It is the programmers responsibility in non-managed environment to rollback the transaction in case of exceptions.
Hibernate never changes the Isolation level of connections obtained from Application server.
Versioning – Numeric Version Field
Without an additional field (not recommended)
Achieved with LockMode.UPGRADE or LockMode.UPGRADE_NOWAIT
Hibernate - LockMode
LockMode.NONE - Don’t go to the database unless the object isn’t in any cache.
LockMode.READ - Bypass all caches, and perform a version check (if applicable) to verify that the object in memory is the same version that currently exists in the database.
LockMode.UPDGRADE - Bypass all caches, do a version check (if applicable), and obtain a database-level pessimistic upgrade lock, if that is supported. Equivalent to LockModeType.READ in Java Persistence. This mode transparently falls back to LockMode.READ if the database SQL dialect doesn’t support a SELECT ... FOR UPDATE option.
LockMode.UPDGRADE_NOWAIT - The same as UPGRADE, but use a SELECT ... FOR UPDATE NOWAIT, if supported. This disables waiting for concurrent lock releases, thus throwing a locking exception immediately if the lock can’t be obtained.
LockMode.FORCE - Force an increment of the objects version in the data-base, to indicate that it has been modified by the current transaction.