Hibernate's transaction management

I. Database transactions

1. Concept:

a database transaction is a sequence of database operations that consists of a single unit, either completely canceled or fully completed. that is, the commit and rollback operations.

2. Features:

(1) atomicity

Multiple database operations that make up a single transaction are non-delimited atomic units, and only all operations succeed, the entire transaction is committed, and any one of the database operations in the transaction fails, and any operations that have already been performed must be revoked to return the database to its original state;

(2) Consistency

The transaction must be logically consistent before and after execution, that is, the data is not destroyed. If the transfer from the a account to the B account, regardlessof the success of the operation, a and b of the total deposit is unchanged;

(3) Isolation

In concurrent data operations, different transactions have their own data space, isolated from each other, and the isolation level can be set.

(4) Durability

Changes to the database are written to the hard disk, if a power outage or system error occurs during the operation, the database must ensure that uncommitted transactions are revoked before the next boot, and that the end transaction writes the result to the hard disk.

3. Classification of the use of transactions

(1) Programmatic Transactions

Direct Use The API of the JDBC, JTA, or related framework sets the boundary and isolation level of the transaction in the manner in which the code is written. ( transactions in JDBC are automatically committed and can be canceled by the Setautocommit (false) method of the Connection object .)

(2) Declarative Transactions

The API(Spring Framework) that relies on the service provided by the application server (WebLogic server) or the associated framework sets the relevant information in the configuration file.

4. Issues that may arise from concurrent access to the database

(1) Dirty reading

A Transaction reads The change data that the B transaction has not yet committed and operates on the basis of this data. That happens to read the data before the B transaction rolls back.

(2) non-repeatable reading

A transaction reads the change data (update and delete) that the B transaction has committed, causing confusion in the data processing. That is , during a transaction two reads,the B transaction is updated or deleted.

To prevent this, you only need to add row-level locks to the operational data to prevent changes in the data in the operation.

(3) Phantom reading

A transaction reads the new data (insert) of the B transaction submission, at which point a transaction will have phantom read. Phantom reads typically occur in transactions that compute statistics.

To prevent this, you need to add a table-level lock that locks the entire table to prevent new data.

(4) first category missing updates

when A transaction is revoked, the updated data of the already committed B transaction is overwritten. This behavior can occur if the database does not have a quarantine transaction.

(5) second category missing updates

when a transaction commits, it overwrites the data already submitted by the B transaction, causing the operation of the B office to be lost.

5. Transaction ISOLATION Level:

Isolation is achieved through the addition of a table or field lock on the database. The transaction isolation level is divided into the following four types:

(1) READ UNCOMMITTED not submitted

One transaction can read data that has been updated but not committed by another transaction, but is not allowed to write until another transaction commits.

(2) Read Committed reading commit (Oracle default transaction)

One transaction can read only the updated data that has been committed by another transaction.

(3) repeatable Read repeat

A transaction has read data that does not allow writing to other transactions.

(4) serialization of Serializable

So the transaction is serialized and cannot be executed concurrently.

√: may appear x: does not appear

Isolation level	Update lost	Dirty Read	Non-REPEATABLE READ	Phantom reading
Read UNCOMMITTED	X	√	√	√
Read committed	X	X	√	√
REPEATABLE READ	X	X	X	√
Serializable	X	X	X	X

Ii. transactions in hibernate

Hibernate is the encapsulation of JDBC , which in itself does not have the ability to transact transactions with the underlying JDBC or JTA processing.

1. Lock

in hibernate , you can not only set different transaction isolation levels of a database by macro angle, but also use optimistic and pessimistic locks to further control concurrent transactions from a micro point of view. (for example, when the data is not allowed to change at settlement time, the data can be locking)

2. Hibernate 's Lock mode

Hibernate can automatically set the lock mode, and can also invoke the load () and Lock () methods of the Session object , Query or Criteria The Setlockmode () method of the object explicitly sets and uses the following pattern.

(1)Lockmode.none

if the If the specified object exists in Hibernate's cache, the object's reference is returned directly, otherwise the object is loaded into the database with the Select statement. This is the default value

(2)Lockmode.read

no matter whether the specified object exists in Hibernate's cache and always loads the object into the database through the SELECT statement.

(3)Lockmode.upgrade

no matter whether the specified object exists in Hibernate's cache, always loads the object into the database through the SELECT statement, or if the database system supports pessimistic locking to execute a select ... for update statement, If the database system does not support pessimistic locks, the normal SELECT statement is executed .

(4)lockmode.upgrade_nowait

and the the Lockmode.upgrade has the same functionality. Also for Oracle databases, execute the select ... for update nowait statement

(5)Lockmode.write

when This pattern is automatically used when Hibernate inserts or updates an object into the database. Hibernate automatically uses this mode when writing data.

3. Pessimistic lock

pessimistic that other transactions are also being accessed every time the database data is read or modified. So pessimistic locks lock the data that is read, and other transactions cannot be accessed.

How to use :

Query of the Setlockmode () Method: Query.setlockmode ("book", Lockmode.upgrade);

Lock () method for Session : session.lock (book, Lockmode.upgrade);

4. optimistic lock

(1) optimistic locking adoption of the version of the strategy is: first commit to the primary (win), post-submission-based (last commit win), Merge conflict update (merge cofilcting updates).

(2)Hibernate recommends using the "version number to achieve the first submission-oriented" optimistic locking mode. Add a column of version to the database, which isread with each read, compares the version number to the version number in the database at the time of the update, and, if it is greater than or equal, can be updated, or throws an exception if it is less than. It is set in the configuration file.

(3) can also use time stamp to achieve optimistic lock, compare time stamp size.

Note: This article refers to "Hibernate development and combat" Liu Wei Zhang Liguo electronic Industry publishing house a book

This article is from the Java My Favorites blog, so be sure to keep this source http://lindianli.blog.51cto.com/7129432/1433111