The cache of sessions and the State of objects in hibernate

The session of this interface learning can be said to be the most painful and the most complex, because it involves too much, some hidden mechanism is also a lot, who let it is the "the".

The study of several of its most basic methods such as Save (), delete (), flush () and so on has taken me a certain amount of time. Before delving into these methods, it is helpful to understand the caching mechanism of the session and the state of the Java objects in hibernate.

A Cache of Sessions

Java is a pure object-oriented language, so it is not possible to manipulate memory directly like C, such as declaring a usable memory space. In Java, caching usually refers to the memory space occupied by the properties of the Java object, usually the attributes of some collection types. A series of Java collections are defined in the implementation class SESSIONIMPL of the session interface, and these Java collections form the cache of sessions.

One obvious benefit of using caching is that it reduces the frequency of database access and improves application performance, because reading data from memory is obviously much faster than querying from a database. According to my personal understanding, the cache of sessions actually acts as a "transition warehouse". Like the Heroes in Warcraft, body will have a bag, used to store commonly used items such as blood potions, magic potion, back to the volume and so on. If you want to use the back of the book and do not have a return roll, you will run to the store to shopping, this will be a waste of time, unless you are at the store right now, and if you want to use it in the back of the book, the hero can be used directly without having to go all the way to the store. Our session of the cache can be said to be equivalent to the hero of the backpack, my application is a hero, and the database is the store slightly, as shown in the following figure.

Of course, this metaphor is not very accurate, for example, in the Hibernate application we can insert a new record in the database, and in Warcraft you are not to the store to increase inventory, but for the sake of understanding, only to make such a comparison.

Two State of Java objects in hibernate

In a hibernate application, Java objects can be in one of the following three states:

1. Temporary state (Transient). Objects in this state are not included in the Hibernate cache management system, are not associated with any session, and there is no corresponding record in the database.

2. Persistent State (persistent). An object in this state is in the session's cache and corresponds to a data record in the database.

3. Free State (Detached). The object in this state is no longer in the session's cache, and the biggest difference between it and the temporary object is that the free object may have a corresponding record in the database.

The above 3 states can be converted to each other, and we say that the state is for one instance of the session, for example, object A is in a persistent state for Session1 because it is in the Session1 cache, But for Session2, object A is not in its cache, so it is in a free state.

The understanding of these states took me a certain amount of time, because there were always some strange thoughts in my mind. For example, for the definition of a temporary state, if I create a new object and then artificially make the value of its attribute correspond to a record in the database, including the ID's value. Can it be said to be in the Free state at this time? Because it corresponds to a record. In fact, these situations are caused by some nonstandard operations. In a hibernate application, an application should not modify its OID regardless of whether the Java object is in a temporary state, a persistent state, or a free state. The value of the OID should be maintained and responsible by hibernate, and in fact hibernate is associated and mapped through the OID when synchronizing the objects in the cache with the records in the database, if the application artificially modifies the object's OID, causing some inexplicable error. And this is not conducive to data synchronization.