Hibernate (ix) level two cache and transaction level details

Preface

This is hibernate's last article, the next series will explain Struts2 things, and then finish Struts2, in to spring, and then write an SSH how to integrate the case. After that, I'm going to talk about SSM, and then my own personal blog should be pretty much done. Basically this is the first set down, start to complete the hibernate thing. At the end of this chapter, I will provide some of my hibernate information for you to study together.

---WH

I. Overview

This chapter is divided into two pieces to explain,

The first chunk, Hibernate's transaction management. , for Hibernate's transaction management, if previously learned the database transaction management, then here is downwind. If you haven't learned it, it's okay to meet for the first time, I'll explain it in detail.

The second chunk, Hibernate's level two cache mechanism. This looks so tall, if you've never known a level two cache, it's hard for someone to find out, but when you learn, it's really easy. At the very least, you'll know what a level two cache is and what it does.

Second, Hibernate's transaction management

　　　　　　2.1. Review the characteristics and isolation level of database transactions

　　　　　　　　　　　　2.1.1, what is a transaction?

A transaction is a set of business logic, such as a to the bank to the B-turn money, a to 100 to B (UPDATE statement updated a money reduction of 100), B received Money (UPDATE statement updated B of the money increased by 100), this transfer money the whole process called transaction, note, do not think a transfer money to B,a finished operation, Is the transaction, remember that the transaction is a set of business logic, two together is the transaction. For example there is a number 5, now there is a transaction a, the thing that a transaction a does is to make 5 4, the transaction to do has, get 5, then 5-1, then the database of 5 into 4, this is the transaction a true success, so to speak, the business logic is too abstract, the transaction is a set of operations, Only the entire operation is considered a transaction. As stated above, the transfer of money is also a business, it does the operation of only two, a reduce money, b increase money.

　　　　　　　　　　　　Characteristics of 2.1.2 and transactions acid

A (atomicity): atomicity: A transaction cannot be divided, is a whole, either succeeds together, or fails together

C (consistence): Consistency, A to 100 to b,a reduction of 100, then B will increase 100, increase the reduction of 100 is consistent meaning

I (Isolation): Isolation, concurrent operation of multiple transactions on the same content.

D (Durability): Persistent, committed transactions have been saved to the database and cannot be changed.

　　　　　　　　　　　　Problems arising from 2.1.3 and transaction isolation

Similar to thread safety, when multiple transactions operate on the same content, a series of concurrency problems occur. It is important to note that this is two or more transactions at the same time to operate on a content, is at the same time, not the first transaction a operation, and then transaction b in operation, this to understand clearly.

　　　　　　　　　　　　　　　　2.1.3.1, Dirty reads : One transaction reads data that is not committed by another transaction.

A to B to 100 dollars ( transaction a), a on the ATM, put 100 dollars into the ATM, and then the ATM opportunity to finally ask a, determine the transfer 100 to B, a is not yet certain this time, B on another ATM machine found that the account of 100 dollars more, And then happy to take away the 100 dollars, b take money ( transaction B) but at this time a feel no, think or take cash to B better, and then point to cancel, put in the ATM machine in 100 dollars to take back. In this case, a transfers money to B (transaction a), B takes Money (transaction B), and a transaction B reads the data not submitted by transaction A, that is, dirty read. Note: To understand what a transaction is, you can understand these things. Also, the first contact may feel that this is not possible, ah, how can read the data has not yet submitted? This is only to explain that this is a problem, the real life is certainly not ah, the bank will not have this problem, because it has all been solved, but this problem must exist, how to solve it? This is what we need to discuss later. Now it's just a matter of knowing that the transaction isolation will produce this problem.

　　　　　　　　　　　　　　　　2.1.3.2, non-repeatable read : One transaction reads data that has been committed by another transaction (UPDATE statement)

Explanation: Sometimes non-repeatable reading is a problem, sometimes it is not. It depends on what the business needs are, just like the bank to transfer money, transaction A (A to B transfer money), transaction B (b take money), a on the ATM card to transfer money to B, and B will also insert the bank card into the ATM machine ready to see if a is transferred to B, when a transaction ends, that is, a transfer success, B found 100 more dollars on his account, which is what transaction B has read about the data that transaction A has submitted. This example is not a problem to read repeatedly. In this business logic, there is no need to address this issue. In other business, maybe this is a problem. For example, a company, 15th per month to pay employees to settle wages, the number of wages from 15th last month to 15th this month according to the amount of work submitted by each person to settle, but accountant a in this month, 15th from the database for each employee's work record amount of data to do payroll statistics, Employee B commits a workload (increasing the workload of B in the database), and when accountant A is settling employee B's salary, it calculates the previous 30 days ' work and the amount of work he has submitted today, to the 15th next month, and the amount of work submitted by employee B in the current month's total workload. In this way, it is equivalent to give B more than one workload of wages. That makes no sense.

　　　　　　　　　　　　　　　　2.1.3.4 , Wasted (Phantom Read): One transaction reads data that has been committed by another transaction (insert INSERT statement)

This is the same as the non-repetition of the description of the problem is the same, but its focus on the transaction is not the same, non-repeatable reading is done to update the transaction, such as transfer money Ah, are doing the update of the transaction, and this virtual read is to do the insertion of the transaction, for example, there are many people work at the site, At noon, the site responsible for the work of the workers to buy lunch box, it is necessary to count, now the site will also use a computer, the person responsible for the computer to check how many people do things, to decide how many bento, in the number of check, another special recruit workers of the head recruit a worker, The worker's information into the database, and then buy the person in charge of the lunch box on the computer to check the database, found that there are n people, just recruit workers in it, and then also to that did not work, just recruit in the staff bought Bento, this is not in line with the rules. This is just to give an example to help you understand that a bento box is not expensive, it does not matter, but if it involves something very important, it can not appear this problem.

　　　　　　　　　　　2.1.4, transaction isolation level, for resolving isolation issues

　　　　　　　　　　　　　　　　2.1.4.1, READ UNCOMMITTED : READ UNCOMMITTED, one transaction read to another transaction no committed data, there are 3 problems, solve 0 problems

　　　　　　　　　　　　　　　　2.1.4.2, Read Committed: Read Committed, one transaction read to another transaction has committed data, there are 2 problems, solve 1 problems (dirty read problem)

　　　　　　　　　　　　　　　　2.1.4.3, repeatableread: Repeatable read, one transaction reads to duplicate data, even if another transaction has already been committed. There are 1 problems, solve 2 problems (dirty read, non-repeatable read)

　　　　　　　　　　　　　　　　2.1.4.4, serializable: Single transaction, at the same time only one transaction can operate, another transaction hangs (paused), there are 0 problems, solve 3 problems (dirty read, non-repeatable read, virtual Read)

Note: Be sure to figure out what the top three questions (dirty read, non-repeatable read, and Phantom Read) are, and you'll know why these four isolation levels can solve these problems. Remember, if you look at my words still think these questions vague, please leave a message to tell me your question, because if you do not understand these three questions, then you will always be confused.

　　　　　　　　　　　2.1.5, using MySQL for isolation level demonstrations

The code is not written here, directly on the text, so that you can familiarize yourself with the use of the transaction isolation level.

By the way, MySQL default isolation level: REPEATABLE READ Oracle Default Isolation level: Read Committed

MySQL default transaction commits, that is, every SQL statement executed in CMD is a transaction, so if you want to experiment you must first turn off MySQL automatic transaction commit, and then manually, set autocommit=0

　　　　　　　　　　　　　　2.1.5.1, READ UNCOMMITTED

　　　　　　　　　　　　　　　　A isolation level: READ UNCOMMITTED, dirty read problem occurs

AB starts the transaction at the same time,

A first query--normal data

b Update, but not committed

A in query-read to B no data submitted

b rollback--B does not commit data, rollback, it is equivalent to the UPDATE statement did not execute

A re-query-read the data after the rollback, which is the original normal data.

　　　　　　　　　　　　　　2.1.5.2, Read Committed

　　　　　　　　　　　　　　　　A isolation level: Read Committed

AB Simultaneous open transaction

A first query--normal

B Update, but not committed

A re-query-to get or the previous data, and did not get B did not submit data, solve the problem: dirty read

B Submit

A re-query-the data that has been submitted. Problem: Non-repeatable read (not in the tangle why not repeat reading is a problem, it has been explained clearly, depending on the business, may be a problem, may not be)

　　　　　　　　　　　　　　2.1.5.3, Repeatable Read

　　　　　　　　　　　　　　　　A isolation: Repeatable reads to ensure that duplicate data is read in the current transaction

AB Simultaneous open transaction

A first query--normal

B Update, but not committed

A re-query--Previous data, resolved: dirty Read

B Submit

A re-query-the previous data, resolved: non-repeatable READ

A Rollback | submit

A re-query-updated data, new transactions to get the latest data

　　　　　　　　　　　　　　2.1.5.3, serializable

　　　　　　　　　　　　　　　　A isolation Level: serialization, single transaction

AB Simultaneous open transaction

A first query--normal

b Update-Wait (the end of transaction A or timeout B can be done.) ）

　　　　　　　　　　2.1.6, missing update problem lost update

This missing update problem is also one of the problems caused by the isolation of things, but different from the above mentioned three, the above mentioned dirty read, non-repeatable read, virtual read, is a transaction to another firm submitted or uncommitted data generated by the problem, and lost updates do not take the data submitted by the other firm, What kind of problem does the missing update describe?

A query data, username = ' Jack ', password = ' 1234 '

B query data, username= "Jack", password= "1234"

A update password, the user name is unchanged username= ' Jack ', password= '456'//a after the password is updated, save it to the database

b Update user name, Username= 'Rose', password= ' 1234 '//b update, data in the database is Username= ' Rose ', password= ' 1234 '

Missing update: Last update data, overwrite the previously updated data. After that a found that the password you just set the login is not on, this has lost the update problem, the solution has two ways

Workaround One:

　　　　　　　　　　　　　　　　　　Optimistic lock

Think that the lost update will not happen, very optimistic, add a field in the database table, it can be said that the identification field is used to record the number of operations, such as if the record has been taken by someone to do the update operation, the field is added 1. And then the next person to get the record is to compare the identity of the recorded record with the identity of the record in the database, if it is the same, it can be modified, and the modified identity (version) +1, if not the same, first query from the database, and then do the update. As an example,

A query data, username = ' Jack ', password = ' 1234 ', version=1

B query data, username= "Jack", password= "1234", version=1//ab simultaneously get the data in the database, and version read as 1

A update password, the user name is unchanged username= ' Jack ', password= '456 ', version=2////and the database in the record version of the comparison, get the version is 1, as in the database, So you can do the update, a will update the password, version+1, and then save it to the database (note that here is the data after a update.) Don't confuse it. )

b Update user name, Username= 'Rose ',password= ' 1234 ', version=1//b when you want to update, compare the version number of the record in the database, find the difference, and then query

b re-query the data, the user name is unchanged username= ' Jack ', password= '456 ', version=2//Then in contrast, this time version, B will be able to implement the update operation.

　　　　　　　　　　　　　　　　　　　　　b Update user name, Username= 'Rose ',password= ' 456 ',version=3//update, version+1 　

　　　　　　　　　　　　　　　　　　　

Workaround Two:

　　　　　　　　　　　　　　　　　　Pessimistic lock

Think that the loss of updates will happen, at this time the use of database lock mechanism, that is, the equivalent of who operation of the record line, it will be added to the lock, others can not go, only when you finish the operation, the lock is released, others will be able to operate. Similar to the isolation level single transaction. But there are many kinds of locks.

Read lock: Shared lock, you can read the data together, but cannot work together (update, delete, INSERT, etc.)

Write Lock: Exclusive lock, only one to write, that is, the principle we said above.

　　　　　　　　

　　　　　　2.2. Hibernate issues and solutions for transaction isolation

The above through a large space to explain the database transaction related issues, is to explain hibernate in the business to pave the way, understand the above, then here is the wind.

　　　　　　　　　　 The transaction isolation level is set in 2.2.1, Hibernate, and the isolation level is designed to address the issue of transactional isolation .

Configuring the Hibernate.connection.isolation Isolation level in the Hiberante.cfg.xml file

There are four isolation levels to choose from, and the following numbers indicate that when the isolation level is set, direct write numbers can also represent the corresponding isolation level, such as Hibernate.connection.isolation 4 and hibernate.connection.isolation Repeatable Read is the same.

Read uncommoitted Isolation 1

Read committed Isolation 2

REPEATABLE READ Isolation 4

Serializable Isolation 8

　　　　　　　　　　　　　　

　　　　　　　　　　Resolution of lost update problem in 2.2.2 and hibernate

Pessimistic lock: It is believed that there will be lost update problems, to take the lock mechanism

User user = (user) session.load (user.class,1,lockmode.upgrade);

Optimistic Lock:

Hibernate adds a version field to the Customer table

1) Add private Integer version to the user class; Version field

2) in User.hbm.xml definition version field

<!--define version fields--

<!--name is a property name--

<version name= "Version" ></version>

　　　　　　　　　　　　　　　　　　　　　　

If a missing update is generated, the exception is reported

　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　Summarize:

1, if you know the database of the knowledge of the transaction, then in Hibernate is very simple, just a simple configuration is OK. Therefore, in the business of hibernate here is less space, it is important to understand the previous knowledge. Very important.

Third, Hibernate's level two cache

Say a bit of crap, two-level cache is really very simple to understand, we do not feel afraid, on three content, know what is a two-level cache, how to use it, there is no.

　　　　　　3.1. What is level two cache

We know the primary cache, and the first level cache is scoped to the session, each session has its own level cache, and the level two cache is more broadly scoped than a cache, storing more content, We know that the session was created by Sesssionfactory, a sessionfactory can create a lot of sessions, each session has its own cache, called a first-level cache, and Sessionfactory has its own cache , the contents are shared for all sessions, that is, level two cache. Isn't it simple? I don't understand. Look at the picture I drew below at a glance.

　　　　　　　　　　　　　　　　

First level cache: Save the session, the transaction scope of the cache (in layman's terms, the session is closed, the cache is gone, its cache can only be used between the session's transaction opening and ending)

Second-level cache, stored in sessionfactory, process-wide cache (the process consists of multiple threads, which is what we mean, a thread may get a session to operate, B-thread may also get a session to operate, But A and B read can access to the cache in the Sessionfactory, that is, the level two cache, here just take a A, a, a, may have a line Cheng gang create a session, you can also get the data in the level two cache)

　　　　　　　　　　

　　　　　　3.2, level two cache role? Advantages

It's probably going to be a real development job to know what the level two cache is for, and now give me some answers that I think are better because I'm not really going to work, so I'm just trying to understand what it is.

。。。。

　　　　　　Internal structure of Cache 3.3, level two

Class Cache Zone

For example: Session.get (customer.class,1); This is the class cache area

Collection Cache Area

Customer.getorders (); The cache area that holds the contents of the Orders collection is called the collection cache area.

Update Timestamp Area

Query Cache Area

These will be discussed in detail in the back, now do not speak, want to see directly on the back of the test example.

　　　　　　Concurrent access policy configuration for 3.4, level two cache.

Why are you explaining this? Think about it, the level two cache is sessionfactory, its sessionfactory created by the session can share it, so there will be a concurrency problem, that is, we began to talk about some of the transaction isolation issues. In order to solve these problems, hibernate also provides the corresponding method, that is, the two-level cache of concurrent access policy, a total of four, through a table to see, through the following picture, we should know that in fact, with the beginning of the same, changed a noun just. And if you want to use a level two cache, you have to configure the ward access policy, or you can not use the level two cache, like you already have a level two cache, which also has content, but you do not set access mode, you can not access it.

　　　　　　　　　　　　　　　　　　　　

After configuring level two caching, the corresponding two-level cache concurrency access policy should be matched accordingly.

　　　　　　3.5. How to configure level two cache?　　　

In two steps, the first step is to configure level two caching, and the second step is to configure the concurrent access policy for level two caching. Step three, configure Ehcache.xml

　　　　　　　　　　3.5.1, configuring Level two caching

To use level two caching, you need to import other components to help us, and hibernate itself has a default level two cache component, but we don't usually use Ehcacheprovider to learn about the two-level cache component providers that Hibernate can support

　　　　　　　　　　　　　　　　　　　　

1, we use Ehcache, so import its jar package

　　　　　　　　　　　　　　　　　　　　

2, configure in the Hibernate.cfg.xml file, turn on level two cache,

　　　　　　　　　　　　　　　　　　　　　

3. Configuring a Level Two cache provider in the Hibernate.cfg.xml file

　　　　　　　　　　　　　　　　　　　　

Turning on level Two caching takes only three steps, three steps above, and then begins configuring our Concurrency access policy.

　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　3.5.2, configuring concurrent access policies for level two caching

The Concurrency access policy that the secondary cache component can support. Why

　　　　　　　　　　　　　　　　　　　　　　

What we're going to use today is Ehcache, which does not support transactional's concurrency access policy, so we're using read-write as a concurrency access policy, and Read-write provides the Read committed transaction isolation level, To prevent dirty reading, the specific function is to look at the above table.

There are two types of configuration scenarios

1. Configuration in Xxx.hbm.xml file

<cache usage= "Read-write" > class level can be configured under the <class> tab

<cache usage= "Read-write" > Collection level can be configured under the <set> tab

2. Configuration in Hibernate.cfg.xml file

　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　3.5.3, configuring Ehcache.xml files　　

Ehcache-failsafe.xml renamed Ehcache.xml in the ehcache-1.5.0 jar package into SRC. This is very simple. If you are using a different component cache, you also have similar files in the same location.

　　　　　　　　　　

　　　　　　3.6, test the existence of level two cache

3.6.1, build test environment

And the above steps to build their own, three-step, note: The use of business logic is dept-staff, that is, the relationship between departments and workers.

1, configure the level two cache, that is, some component cache provider to fix

　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　

2, configure the concurrent access policy, here is in fact freely configured, if you want to only access the value of a class in the level two cache, then configure its access policy in Xxx.hbm.xml

Here, I'll just read-write the Access Policy for dept, and then I'll test it.

　　　　　　　　　　　　　　　　　　　　　　

3. Add Ehcache.xml

　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　3.6.2, test for level two cache presence

　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　 　　

　　　　　　　3.6.3, note that get/load can fetch data from a level two cache, and the list of query cannot fetch data from a level two cache, but its query results are stored in a two-level cache.

　　　　　　　　　　　　　　　　　　　　　　

Summary:

HQL queries can be stored in the first level cache and level two cache, but not from the level two cache

Get\load is able to insert its query data into a primary cache and a level two cache, as well as to take data from a level two cache.

　　　　　　　　3.6.4, first-level cache data synchronizes level two cache

　　　　　　　　　　　　　　　　　　　　　　

Note: If you update the name with HQL, the level two cache is not synchronized, the data in the first-level cache is not changed, the HQL is modified directly against the database, and the set () method is done through the snapshot area in hibernate instead of directly to the database.

　　　　　　　　　3.6.5, test four cache areas in level two cache

　　　　　　　　　　　　　3.6.5.1, class cache zone

Class Cache area, the object that is queried by the ID is put into the class cache area, and its region is cached in the Po object, rather than the individual properties, values, but the complete object, such as the above test whether there is a level two cache, is the ID 2 Dept object into the two-level cache, Instead of the name of the dept, or the ID, if only the name of dept, or any other field property, is placed in the query cache instead of the class cache area.

　　　　　　　　　　　　　3.6.5.2, collection Cache area

Remember the assembly Cascade relationship that I said before, in fact this is the same, such as this dept-staff example, Dept.getstaffset (); The query is put into the collection cache area, and all the PO objects are in the region.

To set the access policy for level two caching, because you want to test the collection cache, set the access policy in its set, and note that the collection-level cache is dependent on the class-level cache, that is, setting the cache in set is not enough because the staff is cached, Therefore, the staff.hbm.xml must also be set to the access policy. At the same time we just test the collection cache, then the query out of the dept can not set the access policy, there is no problem he read it, because we do not need to use. The first one in the red box.

　　　　　　　　　　　　　　　　　　　　　　　　

Staff.hbm.xml

　　　　　　　　　　　　　　　　　　　　　　

Tests whether the staff obtained from dept can be stored in a level two cache.

　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　3.6.5.3, timestamp cache area

Storage of the query results related to the table for inserting, updating, deleting the timestamp of the operation, hibernate through the timestamp cache area to determine whether the cached query results expire, if it expires the data from the database, not expired, and directly from the cache to take the data. In layman's words, three steps.

1. The result of the query is placed in the level two cache, at which time the record is T1

2, when the operation directly changes the database data, such as using the HQL statement, the database will be directly modified, without changing the data in the cache. The recording time is T2

3, when the next time in the query record, will first compare T1 and T2, if T2>T1, then the data in the cache is not up-to-date, then the correct data from the database, if t2<t1, it means that there is no modification of the database operation, Then you can get the data directly from the cache.

Doubts: If there is no comparison between T1 and T2, then the data we have to query is not accurate, because as mentioned in the second step above, the data of the database will be different from the data in the cache, what read does not do is to take the data from the cache, there will be an error.

Test:

　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　

　

　　　　　　　　　　　　　3.6.5.4, query cache area

This is almost already explained in the class cache area, that is, the result of the query is not a PO object, but some scattered field properties, then it is stored in the area, but it takes two things to use it

1. Configure in the Hibernate.cfg.xml file

　　　　　　　　　　　　　　　　　　　　　　

2, when using the query operation, you need to specify whether to get the data from the queries cache

　　　　　　　　　　　　　　　　　　　　　　

Test:

　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　

The above write access policy is all used Xxx.hbm.xml to configure, now I will use the above example of Hibernate.cfg.xml to configure the access policy code to write a bit.

　　　　　　　　　　　　　　　　　　

Two cache zones are used, the timestamp cache area is not set, and the query cache area is set by other means. This is the four cache area we're going to be explaining. Very simple.

Iv. Summary

This article should have been written early, but the halfway because of some things and delayed, this morning finally finished it. Hiberante I think it's almost these things. I hope to be of some help to everyone

Hibernate (ix) level two cache and transaction level details