The document discusses transaction concepts and concurrency strategies in Hibernate. It defines the ACID properties of atomicity, consistency, isolation, and durability. It also describes programmatic transaction demarcation options in Hibernate and how exceptions are handled. Finally, it discusses concurrency strategies like optimistic and pessimistic locking and Hibernate's support for different lock modes.

1. Transaction and Concurrency Session - III

2. TRANSACTION – FAST BRUSH UP Atomicity – refers to the ability that, either all of the tasks of a transaction are performed or none of them are. Consistency - refers to the database being in a legal state when the transaction begins and when it ends. Isolation - refers to the ability of the application to make operations in a transaction appear isolated from all other operations. Durability - refers to the guarantee that once the user has been notified of success, the transaction will persist, and not be undone.

3. Programmatic Transaction Demarcation java.sql.Connection – To be avoid in Hibernate application as it binds to plain JDBC environment. javax.transaction.UserTransaction – should be used in Java EE application/JTA supported environment. org.hibernate.Transaction – Unified transaction demarcation for Hibernate application; works both in managed and non-managed.

4. Transactions & Exceptions Hibernate 3.x exceptions are typed runtime exceptions. HibernateException – generic exception. JDBCException – thrown by hibernate internal JDBC layer. Subtypes – JDBCConnectionException SQLGrammarException LockAcquisitionException DataException ConstraintViolationException

5. 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.

6. Concurrency Strategies Hibernate never changes the Isolation level of connections obtained from Application server. Optimistic Versioning – Numeric Version Field Timestamp based Without an additional field (not recommended) Pessimistic Achieved with LockMode.UPGRADE or LockMode.UPGRADE_NOWAIT

7. 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.

8. 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. Hibernate – Lock Mode (Cont..)