Hibernate (4) structure-Basic Semantics and transactions, and hibernate Semantics

Hibernate (4) structure-Basic Semantics and transactions, and hibernate Semantics
I. Basic Semantics

Core:

• Configuration
• SessionFactory
• Session

Ii. Configuration

The Configuration class is responsible for managing the Configuration information of Hibernate. During Hiber running, you need to obtain some basic information about the underlying implementation.

1. Database URL

2. database users

3. Database User Password

4. Database JDBC driver

5. Database dialect is used to provide support for specific databases, including the implementation of specific database features.

When Hibernate is called, Hibernate automatically searches for the configuration file in the current CLASSPATH, hibernate. cfg. xml, and reads it into the memory as the basic configuration for subsequent operations.

Configuration config=new Configuration().configure();

The Configuration class is generally only required when obtaining SessionFactory. After obtaining SessionFactory, the Configuration information is maintained by Hibernate and bound to the returned SessionFactory, therefore, you generally do not need to perform operations on it.

You can also use a custom file name without the default file name, but it must be in. xml format.

File file=new File("c:/myhibernate.xml");Configuration config=new configuration().configure(file);

Iii. SessionFactory

SessionFactory negatively creates Session instances

        SessionFactory factory=new Configuration().configure().buildSessionFactory();

Iv. Session

Session session=new Configuration().configure().buildSessionFactory().openSession();

Then you can call the save, find, flush and other methods provided by the Session to complete the persistent layer operations.

Hibernate automatically runs the flush method when the transaction is committed.

When the Session is closed, the flush method is automatically executed.

If the data is not in the transaction, add, delete, modify, and query the data, use flush () to force the database synchronization.

V. Transaction Management

Hibernate is a lightweight encapsulation of JDBC and does not provide transaction management capabilities.

Hibernate delegates transaction management to the underlying JDBC or JTA

<? Xml version = '1. 0' encoding = 'utf-8'?> <! DOCTYPE hibernate-configuration PUBLIC "-// Hibernate/Hibernate Configuration DTD 3.0 // EN" "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd"> <! -- Generated by MyEclipse Hibernate Tools. --> Vi. JDBC-based transaction management
// Obtain SessionSession session = new Configuration (). configure (). buildSessionFactory (). openSession (); // open the Transaction tran = session. beginTransaction (); // submit the transaction tran. commit ();
The following section of Hibernate only encapsulates JDBC.
// Obtain the database Connection dbconn = getConnection (); // set automatic submission to false dbconn. setAutoCommit (false); // submit dbconn. commit ();
In openSession (), hibernate initializes the database connection, and sets AutoCommit to disabled to false.
In the session. beginTransaction () method, Hibernate will confirm again that the AutoCommit attribute of Connection is set to disabled.
It is used to prevent the user code from modifying the Connection. AutoCommit attribute of the Session.
That is to say, the automatic submission attribute of the Session obtained from SessionFactory () has been disabled.
VII. JTA Transaction Management 7.1. JTA introduction Java Transaction API (JTA: Java Transaction API) and its fellow Java Transaction Service (JTS: Java Transaction Service ), the distributed transaction Service (distributed transaction) is provided for the J2EE platform ). A distributed transaction (distributed transaction) includes one transaction manager and one or more resource managers ). A resource manager is a type of persistent data storage. The transaction manager is responsible for the communication between all transaction participants. 7.2. JTA and JDBCJTA transactions are more powerful than JDBC transactions. A jta transaction can have multiple participants, while a JDBC transaction is limited to a single database connection. Any of the following Java platform components can be involved in a JTA transaction: JDBC connection, JDO PersistenceManager object, JMS queue, JMS topic, Enterprise JavaBeans (EJB) A resource distributor compiled using the J2EE Connector Architecture Specification. 7.3 JTA features
JTA provides cross-Session transaction management capabilities
JTA transaction management is implemented by the JAT container. The JTA container debugs many connections that are currently added to the transaction.
The JTA transaction cycle can span multiple JDBC Connection lifecycles
JTA transactions are maintained by JTA Container, and the Connection of the transaction does not require interference from transaction management.
VIII. Lock Mechanism in transactions
During the implementation of business logic, data access needs to be exclusive.
Lock the selected target data and cannot be modified by other programs.
Hibernate supports two lock mechanisms: Pessimistic Locking and Optimistic Locking ).
8.1,Pessimistic lock
This refers to the conservative attitude towards data being modified by the outside world (including other current transactions of the system, as well as transactions from the external system). Therefore, during the entire data processing process, lock data
Pessimistic locks are implemented based on the locks provided by the database. Only the locks provided by the database can ensure data access exclusive. Otherwise, even if the lock mechanism is implemented in the system, it cannot guarantee that the external system will not modify the data.
Pessimistic lock in Oracle
select * from login where username='aaaa' for update;

8.2,Optimistic lock
Compared with the pessimistic lock, the optimistic lock mechanism adopts a more loose locking mechanism.
Optimistic locks are mostly implemented based on the data Version record mechanism.
When reading data, read the version number together. When updating the data, add a version number. At this time, the version data submitted is compared with the current version information recorded in the database table, if the submitted data version number is greater than the current version number of the database table, update the data. Otherwise, the data is deemed to have expired.

 

 
  
Optimistic Locking mechanism avoids the lock overhead of the database in long transactions
 
  
Optimistic Locking mechanisms are often based on the data storage logic in the system, so they also have certain limitations.
 
  
Hibernate has built-in optimistic lock implementation in its data access engine.

 
Optimistic Locking policies can be implemented in the database stored procedures. Only data update Methods Based on the stored procedures can be opened to the outside, rather than making the database tables public to the outside.