Hibernate three States (Transient, Persistent, Detached) Various save (save, persis

One or three States (Transient, Persistent, and Detached) have three states in Hibernate. With deep understanding of it, we can better understand the running mechanism of hibernate. At the beginning, we didn't pay much attention to these concepts, later I found it important. Better understanding of the relationship between hibernate, JVM, and SQL. For JAVA objects that require persistence, there are three states in their lifecycles and they are converted to each other. 1. Temporary State (Transient): the object created with new is not Persistent, not in Session, and the object in this state is called a temporary object; 2. Persistence (Persistent ): it has been persisted and added to the Session cache. For example, the object saved through the hibernate statement. Objects in this state are called persistent objects; 3. Detached: objects in the Session state are separated from persistent objects. For example, the Session cache is cleared. Feature: It is persistent but not in Session cache. Objects in this state are called free objects; ×√ temporary (Transient) Persistent (Detached) whether there is a corresponding record in the Session cache * √ similarities and differences between the free object and the temporary object: both are not associated with the Session, and the object attributes and the database may be inconsistent; the free object is converted from the persistence object closing Session, and there are objects in the memory, so it becomes a free state at this time. The figure is the essence: 2. Differences between various types of storage (save, persist, update, saveOrUpdte, merge, flush, lock) instances in the Free State can be persisted by calling the save (), persist (), or saveOrUpdate () method. A persistent instance can be detached by calling delete. The instances obtained through the get () or load () method are in a persistent state. You can call update (), 0 saveOrUpdate (), lock (), or replicate () for persistence of an instance in the unmanaged state. Save () and persist () will trigger SQL INSERT, delete () will trigger SQLDELETE, and update () or merge () will trigger SQLUPDATE. Modifications to persistence instances are detected during refresh and submission, and SQLUPDATE is also caused. SaveOrUpdate () or replicate () may cause SQLINSERT or UPDATE 2.1 save and update to put this pair first because this pair is the most commonly used. The function of save is to save a new object. update is to save an object out of management. The difference between 2.2 update and saveOrUpdate is better understood. As the name suggests, the saveOrUpdate is basically a synthesis of a section in the save and update references hibernate reference to explain their usage and differences. Generally, update () or saveOrUpdate () will be used in the following scenarios (): the program loads objects in the first session. This object is passed to the presentation layer object. Some changes have occurred. This object is returned to the business logic layer. The program calls the update () of the second session () method to persist these changes saveOrUpdate () to do the following: if the object has been persisted in this session, if another object associated with this session has the same persistent identifier (identifier), an exception is thrown. If the object does not have the identifier attribute, save () If the object's persistent identifier (identifier) indicates that it is a new instantiated object, call save () if the object contains version information (via <version> or <timestamp>) and the value of the version attribute indicates that it is a new instantiated object, save () It. Otherwise, the update () object 2.3 persist differs from save. This is the most specific pair. On the surface, it seems that any one of them can be used. They are not clearly distinguished in the hibernate reference document. A clear distinction is given here. (You can follow up with src to see if the implementation steps are similar, but there are still slight differences.) For details, see explain found that a lot of people have the same doubt. to help to solve this issue I'm quoting Christian Bauer: "In case anybody finds this thread... persist () is well defined. it makes a transient instance persistent. However, it doesn' t guarantee that the identifier value will be assigned to the persistent instance immediately, the assignment might happen at flush time. the spec doesn't say that, which is the problem I have with persist (). persist () also guarantees that it will not execute an INSERT statement if it is called outside of transaction boundaries. this is useful in long-running conversations An extended Session/persistence context. A method like persist () is required. save () does not guarantee the same, it returns an identifier, and if an INSERT has to be executed to get the identifier (e.g. "identity" generator, not "sequence"), this INSERT happens immediately, no matter if you are inside or outside of a transaction. this is not good in a long-running conversation with an extended Se Ssion/persistence context. "Begin simple translation of the main content of the above sentence: 1. persist persists a transient instance, but" not guaranteed "the identifier is immediately entered into the persistent instance, enter the identifier may be postponed to the flush time. 2. persist "guarantee". This function is useful when it is called outside a transaction and does not trigger an SQL Insert statement, when we encapsulate a long Session flow by inheriting Session/persistence context, a function like persist is required. 3. save "does not guarantee" 2nd. It must return the identifier, so it will immediately execute SQL insert, whether in transaction or external 2.4 saveOrUpdateCopy, the difference between merge and update indicates that merge is used to replace saveOrUpdateCopy. For details, see the article at the end (the new Session interface of hibernate 3.2 is different from the previous interface) then compare the functions of update and mergeupdate. Here we will talk about the instances of merge if the session contains the same persistent identifier (identifier, overwrite the old persistent instance with the object state provided by the user. If the session does not have a corresponding persistent instance, try to load the instance from the database or create a new persistent instance, finally, the object given by the user of the persistent instance is returned and is not associated with the session. The key point of this object is the last sentence: When we use update, after the execution is complete, the status of object A we provide changes to holding Long state, but when we use merge, the execution is complete. The object A we provide is still in the unmanaged state, hibernate or new B, or A persistent object B is retrieved, and copy all the values of object A we provide to this B. After the execution is complete, B is in A persistent state, the difference between the managed State 3.5 flush and update provided by A is better understanding that the update operation is an object in the unmanaged state, while the flush operation is an object in the persistent state. By default, objects in a persistent State do not need to be updated. As long as you change the object value, the objects will be automatically saved to the database after hibernate flush. Hibernate flush occurs in several situations: 1. 2 when calling some queries, 3 when using transaction commit, when you manually call flush, the difference between 3.6 lock and update is to change an object that has been changed to the persistent state lock, which changes an object that has not been changed to the unmanaged state the persistent status changes the content of a record, the two operations are different: update operation steps are: (1) Change the unmanaged object-> call updatelock operation steps are: (2) call lock to change the object from the unmanageable state to the persistent state --> change the content of the object in the persistent state --> wait for flush or manually flush to attach: in hibernate 3.2, the new Session interface is different from the previous session interface in hibernate 3. In the hibernate3.2 version, the session has two new session interfaces: org. hibernate. old Session interface of the session: or G. hibernate. classic. Session, as the name suggests, the session under the classic package is a commonly used session. The new one is greatly changed compared with the old one. 1 is listed in detail below. All the find methods are removed and there is no find method in the new session interface. In the old session interface, all the find methods are commented into deprecated. 2. Remove all saveOrUpdateCopy and use merge instead. This is classic. the original statement in the Session comment. /*** Copy the state of the given object onto the persistent object with the same * identifier. if there is no persistent instance currently associated with * the session, it will be loaded. return the persistent instance. if the * given instance is unsaved or does not exist in the database, save it and * return it as a newly persistent in Stance. otherwise, the given instance * does not become associated with the session. ** @ deprecated use {@ link org. hibernate. session # merge (String, Object)} ** @ param object a transient instance with state to be copied * @ return an updated persistent instance */Note this sentence: @ deprecated use {@ link org. hibernate. session # merge (String, Object)} 3. If the iterate method is removed, createQuery is used to obtain iterate4 and the filter method @ deprec is removed. Ated use {@ link # createFilter (Object, String )}. the note given by {@ link Query # list} is replaced by createFilter. Actually, you get the query from createFilter and Query it by yourself. 5. You have added some methods to read the api by yourself, it mainly provides some new functions. Summary: From the changes above, it is not difficult to see that hibernate's concept of interface settings has changed. The previous policy was as follows: Provide full interfaces as much as possible to reduce the amount of user code. Therefore, the filter directly returns collection, and the iterate directly returns iterate. However, this result is excessive interface provision, resulting in a learning burden and a selection burden. It is troublesome to remember these functions and choose among them. Anyone who is familiar with java knows that the hardest thing to use java is to choose a suitable project in the open-source world, then select the implementation method in the selected project because there may be many implementation methods, and some are still deprecated. Current policy: simplify the interface, reduce the function, or simplify the function name, for example, convert saveOrUpdateCopy to merge. The advantage is that there is less Memory Learning Burden. Writing a few more codes is not very troublesome. In fact, I personally prefer the current feeling. In fact, the previous strategy is to meet the individual needs of programmers and have a sense of accomplishment. But it is not suitable for users' needs. OK, no matter what the current situation is better.