You can't understand it. You can take a picture of me-object status in the orm framework.

Whether ejb3.0 or hibernate, they are collectively referred to as the ORM framework. Although each framework has its own understanding of the object state, it is inevitable that there are something common.

In hibernate, the object states are divided into transient, persist, and detached. in EJB, there are four States: New, managed, detached, and removed.

Specifically, transient and new correspond to no id value (what does this ID mean later) and have not been placed in the database image (sessionfactory, persistencecontext) to modify the data, the data in the database will not change.

Persist corresponds to managed, which is an object managed by a container, also known as a persistent object. Operations on this object will affect the data in the database.

The detached of the two is the same as that of the offline object. This indicates that the object is not deleted, but the object management object is closed, not deleted.

The deviation between the two on the object state is that the EJB has a removed State while the object enters this state after you remove the object. In hibernate, if the remove method is called, the object enters the transient state. Currently, there are not many contacts with the removed state, so it will be classified as the transient state for the time being. In fact, there is a certain reason for such an analysis of EJB. The following is a detailed description.

The ORM classifies the status based on the ID and whether it is managed:

As we all know, when using these two Orm, apart from declaring classes as entity, an indispensable step is to declare the ID generation policy. The new object will be assigned an ID to the object after the Save method is called by the session or entitymanager (which is later agreed to be the session). This object will be managed by the session and has an ID at the same time. That is, the object in the persist State. If the object in this state is modified, the update method of the session is called by default.

The new object is in the transient state before saving. At this time, the object is not assigned an ID and is not managed by the container. Therefore, no matter how you modify it, it is just an ordinary Java object.

For objects in the detached state, If you disable the session at this time, the object has an ID instead of being managed by the container. Therefore, from a certain perspective, it's just an ID-based transient object. That is to say, you need to create a new object and assign values to the Object ID. This object can be called a detached object, however, the value in it is slightly different from the value in the database. If you call the update method explicitly, if your ID is in the database, it can be updated.

The reason why EJB is divided into four types is that he has dug a hole for himself. The description of New is as follows: there is no id value and it has not been managed by the container. In fact, this is simple and easy to accept. This is actually what I understand, because it is easy to understand and can clearly guess what his execution process has done. However, this class is no longer managed by the container during the remove operation, but it has an ID value and does not exist in the database. These three values include the features of new and detached at the same time, the removed state cannot be added to any of the two categories.

Later, let's look at hibernate's description of transient: Objects initialized using the new operator are not immediately persistent, and they are not associated with database tables, as long as the application does not reference these objects, their status will be lost and recycled by the garbage collection mechanism. Therefore, after the remove method is called, the object becomes an instantaneous object.

Compared with the description of hibernate, it is more abstract, but it is difficult to understand, because if you do not view the object status by yourself, you do not know what is the difference between transient and persist, the specific description of EJB will find that the abstract is not enough. We hope to use the following table to describe the object status in the orm.

(The object state in the EJB is in the brackets)

The status transition between them is as follows: