ACID Transactions

1
ACID Transactions

• What is Transaction ?
• Transaction is a unit of work. Several operations
  are grouped together as a single indivisible unit
  of work.
• Transaction Properties
• Atomic
• A transaction completes successfully or it fails.
  
• All the operations in a transaction appear as one
  unit of work
• If one operation fails, the entire unit of work
  fails.
• Consistency
• Consistency means that any transaction works with
  a consistent set of data and leaves the data in a
  consistent state when the transaction completes.
• It preserves the internal consistency of the data
  it acts on.
• Isolation
• Transactions allow multiple users to work
  concurrently with the same data without
  compromising the integrity and correctness of the
  data.
• A particular transaction shouldnt be visible to
  and shouldnt influence other concurrently
  running transactions.
• Transactions appear to execute serially, even if
  they are actually executed concurrently.
• Durability
• The effects of a committed transaction are never
  lost.
• Durability guarantees that once a transaction
  completes, all changes made during that
  transaction become persistent

2
Hibernate Transaction API

• Transaction management is exposed to the
  application developer via the Hibernate
  transaction interface.
• The Transaction interface provides methods for
  declaring the boundaries of a database
  transaction.
• Transaction API
• Transaction tx session.beginTransaction()
• Call to session.beginTransaction() marks the
  beginning of a database transaction.
• tx.commit()
• tx.commit() synchronizes the Session state with
  the database
• tx.rollback()
• This method either rolls back the transaction
  immediately or marks the transaction for
  rollback only.
• Flushing the Session
• Flushing the session state to the database at the
  end of a database transaction is required in
  order to make the changes durable.
• Hibernate flushes occur at the following times
• When a transaction is committed
• Sometimes before a query is executed
• When the application calls Session.flush()
  explicitly

3
Isolation Issues

• Isolation Issues
• Lost Updates
• Two transactions both update a row and then the
  second transaction aborts, causing both changes
  to be lost.
• Dirty Read
• One transaction reads changes made by another
  transaction that hasnt been committed yet.
• Unrepeatable read
• A transactions reads a row twice and reads
  different state each time.
• Phantom read
• A transaction reads a query twice and the second
  result set includes rows that werent visible in
  the first result set

4
Isolation Levels

• Isolation Levels
• Read uncommitted
• Permits dirty reads but not lost updates
• One transaction may not write to a row if another
  uncommitted transaction has already written to
  it.
• Implemented using exclusive write locks
• Read committed
• Permits unrepeatable reads but not dirty reads
• Reading transactions dont block other
  transactions from accessing a row. However, an
  uncommitted writing transaction blocks all other
  transactions from accessing the row.
• Implemented using shared read locks and exclusive
  write locks
• Repeatable read
• Permits neither unrepeatable reads nor dirty
  reads.
• Phantom reads may occur.
• Reading transactions block writing
  transactions(but not other reading transactions),
  and writing transactions block all other
  transactions.
• Serializable
• Provides the strictest transaction isolation.
• It emulates serial transaction execution.
• Setting Isolation level
• Hibernate configuration option
• hibernate.connection.isolation4

5
Hibernate Lock Modes

• The Hibernate LockMode class lets you request a
  pessimistic lock on a particular item.
• Transaction tx session.beginTransaction()
• User user (User)session.get(User.class, userid,
  LockMode.UPGRADE)
• user.setPassword(123456)
• tx.commit()
• LockMode.NONE
• Dont go to the database unless the object isnt
  in either cache.
• LockMode.READ
• Bypass both levels of cache an perform a version
  check to verify that the object in memory is the
  same version that currently exists in database
• LockMode.UPGRADE
• Bypass both levels of cache, do a version check
  and obtain a pessimistic upgrade lock.
• LockMode.UPGRADE_NOWAIT
• Throws an exception if lock cannot be obtained.
• LockMode.WRITE
• Is obtained automatically when Hibernate has
  written to a row in the current transaction.
• Cannot be specified explicitly as it is an
  internal mode

6
Application Transactions

• Application user considers a single unit of work
  as one transaction. These are coarse grained
  transactions. Database transactions are fine
  grained.
• Data must remain consistent throughout the
  application transaction
• Three ways to handle the concurrent attempts to
  write to the database
• Last commit wins
• Both updates succeed, and the second update
  overwrites the changes of the first. No error
  messages are shown.
• First commit wins
• The first modification is persisted, and the user
  submitting the second change receives an error
  message. The user must restart the business
  process by retrieving the updated contents.
• Merge conflicting updates
• First modification is persisted, and the second
  modification may be applied selectively by the
  user
• Hibernate implements the second and third
  strategies using managed versioning for
  optimistic locking.

7
Caching theory and practice

• A cache keeps a representation of current
  database state close to the application, either
  in memory or on disk of the application server
  machine. The cache is a local copy of the data.
  Cache sits between an application and database.
• Caching strategies and scopes
• Transaction scope
• Attached to the current unit of work.
• Every unit of work has its own cache.
• Process scope
• Shared among many transactions
• Data is accessed by concurrently running
  transactions, obviously with implications on
  transaction isolation.
• Cluster scope
• Shared among multiple processes on the same
  machine or among multiple machines in a cluster
• For a typical enterprise level application, it
  is desirable that the scope of object identity is
  limited to a single unit of work.
• Transaction scope is the first level mandatory
  cache.
• Process or cluster scope provides the optional
  second level of caching.

8
Hibernate cache

• First level cache is the Session itself. Cache
  associated with the Session is a transaction
  scope cache.
• Session cache ensures that when the application
  requests the same persistent object twice in a
  particular session, it gets back the same
  (identical) instance.
• Session cache ensures
• Avoids unnecessary database traffic
• There can never be conflicting representations of
  the same database row at the end of a database
  transaction.
• Changes made in a particular unit of work is
  almost instantly visible to all other code
  executed inside that unit of work.
• Session cache is always on and cannot be turned
  off.
• Second level cache is provided by external
  providers