first, transaction characteristics
A atomicity: The smallest indivisible unit (either wholly successful or all failed)
B Consistency: The transaction must transform the database from one consistency state to another consistent state.
For example, the balance of the two accounts before the transfer is 1000, and the balance of the two accounts after the transfer is 1000.
C isolation: In a multithreaded environment, transactions in one thread cannot be disturbed by transactions in other threads.
D Persistence: Once a transaction is committed, it should be permanently preserved. second, the transaction concurrency problem
A dirty read: Read the data that other people are working on.
B non-repeat read: two consecutive reads, inconsistent data.
C Phantom (virtual) read: A transaction in one thread reads data from an insert commit in another thread. the isolation level of the transaction (used to resolve transactional concurrency issues)
A read not submitted--may appear ABC
B Read submitted--BC
C Repeatable Read--c (MySQL default level)
D serialization--no problem, too inefficient Four, specify the isolation level of the database in Hibernate
#hibernate. Connection.isolation 1|2|4|8
Specify isolation level with one byte
0001--1 (read not submitted)
0010--2 (read submitted)
0100--4 (Repeatable Read)
1000--8 (serialized)
Hibernate.cfg.xml
<!--Specifies the isolation level when hibernate operations the database--> (the project is in the actual condition of isolation level)
<property name= "Hibernate.connection.isolation" >4</property> v. How to manage transactions in a project
A business is opened before the business is executed, and the transaction is committed after execution.
An exception occurred during execution, rolling back the transaction.
B you need to use the Session object in the DAO layer to manipulate the database.
The service control transaction is also done using the session object. We need to make sure that the DAO Layer and service layer use the same session object.
C in Hibernate, make sure that you use the same session problem,
Hibernate has been resolved, the developer only needs to call Sf.getcurrentsession () to get the session object that is bound to the current thread.
NOTE 1: Calling the Getcurrentsession method must be configured with a section of the primary configuration file.
Hibernate.cfg.xml
<property name= "Hibernate.current_session_context_class" >thread</property>
public void Function1 () {
Returns a session that is bound to the thread each time
Session Session1 = Hibernateutils.getcurrentsession ();
Session Session2 = Hibernateutils.getcurrentsession ();
System.out.println ("Session1 = = Session2");//true
}
public void function2 () {
Each time you get a new session
Session Session1 =hibernateutils.opensession ();
Session Session2 =hibernateutils.opensession ();
System.out.println ("Session1 = = Session2");//false
}
NOTE 2: The session object obtained through Getcurrentsession () is automatically closed when a transaction is committed, and do not manually call close shutdown. Six, code optimization
public class Customerdaoimpl implements Customerdao {
public void Save (Customer c) {
1. Get Session
Sessionsession = Hibernateutils.opensession ();
2. Open transaction
Transactiontx = Session.begintransaction ();
3. Execute Save
Session.save ();
4. Submission of services
Tx.commit ();
5. Closing Resources
Session.close ();
}
}
public class Customerdaoimpl implements Customerdao {
public void Save (Customer c) {
1. Get Session
Session session = Hibernateutils.getcurrentsession ();
2. Execute Save
Session.save ();
}
}
public class Customerserviceimpl implements CustomerService {
Private Customerdao Customerdao = new Customerdaoimpl ();
public void Save (Customer c) {
Session session = Hibernateutils.getcurrentsession ();
1. Open transaction
Transaction TX =session.begintransaction ();
2. Invoke DAO Save Customer
try {
Customerdao.save (c);
catch (Exception e) {
E.printstacktrace ();
3. Transaction Rollback
Tx.rollback ();
}
3. Closing the transaction
Tx.commit ();
}
}