List of States

And now the fun begins. We will study the states of Entity objects. You have to pay for everything, and for using Hibernate too. Don't you think that learning HQL is such a price? No, life is a little more complicated.

If you have some kind of Entity object that you can save to the database using Hibernate, then from the point of view of Hibernate, this object can have four states:

  • Transient
  • Persistent (or Managed)
  • Detached
  • Removed

And to interest you, I will add this picture to this lecture:

Life cycle of Hibernate Entity objects

Transient

In fact, everything is much simpler than it seems, although not without nuances. For example, every Entity object that you explicitly created using Java code, and did not load from the database using Hibernate, has a Transient (transparent) status.

EmployeeEntity employee = new EmployeeEntity();

The Transient status means that Hibernate has no idea about this object, and no action on the object affects Hibernate, nor does Hibernate's work on this object.

Java university

Such objects are also called POJO - Plain Old Java Object . The term is often used as the opposite of various objects with tricky behavior. Remember the Moc objects that Mockito created? Here they are not POJO.

If some client code works with an object with the Transient status, then their interaction can be described by a super-simple scheme:

POJO

Persistent or Managed

The next most common case is objects related to the Hibernate engine. Their status is called Persistent (or Managed). There are exactly two ways to get an object with this status:

  • Load object from Hibernate.
  • Save object in Hibernate.

Examples:

Employee employee = session.load(Employee.class, 1);
Employee employee = new Employee ();
session.save(employee);

Such an object usually corresponds to some kind of record in the database, it has an ID and the like. This object is attached to the Hibernate session, and in general can be represented not by a real object, but by some kind of proxy.

It is quite possible that after calling the session.load() method , you will get back some stub object (proxy), and all calls to the database will be performed only after calling the methods of this object. But we will talk about such details a little later.

And the interaction between the client code and the object in the Managed status can be described with the following picture:

Persistent object

Detached

The next state is when the object has been detached from the session. That is, once the object was attached to the Hibernate session, but then the session was closed or the transaction ended, and Hibernate no longer monitors this object.

Example:

session.close();
session.evict(entity);

In the first example, the session was closed. In the second case, we have explicitly indicated that we want to detach the object from the session using the evict() method .

The new code-object interaction scheme will look like this:

And here is where it gets interesting. If your object was obtained from Hibernate, then it is likely that you were given a proxy instead of a real object. And this proxy object, after disconnecting from the session, will throw exceptions when its methods are called.

This is the most common problem for all beginners when working with Hibernate. You need to know exactly at any given time the answer to questions like this when you're working with an Entity object :

  • Do you have a real object or just a proxy from a real object?
  • Are you currently in a transaction or not?
  • Is it a read-write transaction or a read-only transaction?
  • Is the object managed by the LazyLoading mechanism?
  • Which parts of the object are already loaded into memory, and which parts will be loaded when accessed?
  • How is your object connected to dependent objects?

The good news is that most of the time it's obvious. But you still need to understand how it all works under the hood. Declarative programming is what it is - you can write code in 10 minutes, understand why it does not work as it should - in 10 hours :)

Removed

And the last state your Entity object can have is Removed. As you probably already guessed from its name, this is the state of a remote object.

This state appears due to the fact that if you delete some object from the database, then the Java object will not immediately disappear anywhere.

Employee employee = session.load(Employee.class, 1);
//after loading the object's state is Persisted

session.remove(employee);
//after deletion, the state of the object is Removed

session.save(employee);
//and now Persisted again

session.close();
//and now the Detached state