Why need detached entities in JPA?

Question

There are always so many questions related to issues with detached entities!

First, they often cause LazyInitializationException in Hibernate. Yes, there ar

Answer 1

It could be that an entity is seen as detached because it has the same ID as an entity in the persistence store. Imagine you got the entity from outside of the application. It could be that this entity is seen as detached when trying to persist it. There for you have to attach it again with, indeed, the merge.

I can't really imagine other situations and I'm curious for the other answers.

Answer 2

I will explain why that scenario should not occur and why we need detached entities.

Consider you are in a JTA transaction (JPA requires support for it) and fetch a. Now you can call a.getB() either (1) in this transaction (i.e entity a is managed) or (2) when a is detached.

Scenario 1: now depending on your transaction isolation level, you might see or might not see what other transactions do. For example, if you have the SERIALIZABLE isolation level, then you will successfully fetch a.getB(), even if that row was deleted in a concurrent transaction. If that row was already deleted and your transaction sees that, it means that either your DB is inconsistent (no foreign key) or that you used the wrong transaction isolation level.

Scenario 2: the entity a is detached. When a LazyInitializationException is thrown, that means to me that you called a.getB() too late in order to guarantee a consistence in your application (as a is not managed anymore). In order to solve the problem you simply call it earlier when the entity is still managed. A NPE cannot occur.

Why we need the DETACHED STATE? Well, we need a state in which the changes to an entity instance are not tracked. Why?

Example 1: suppose you receive an entity (with persistent identity) in the EJB layer and that there were no detached state (meaning all entities should be managed). But we need to do a validation before persisting the entity. If that entity would be automatically managed, its changes would be automatically persisted to DB. So this new state was introduced.

Example 2: you receive in the EJB layer an entity, any you need to update ONLY 5 fields of 10 from that entity. If that entity would get automatically into the managed state, all 10 fields would be persisted. The solution in this case is to fetch a managed entity and to update the 5 fields ONLY in that entity.

Answer 3

Detached entities (eagerly fetched) could work as DTOs in some cases. Probably not something that should be done in an enterprise application, but e.g. a java se based network game, where both the server and client come from same codebase, the player state could be reprented as entity and be transfered to/from server and persisted there.

Not sure that it would be a better choise than proper DTO, but it could be technically done.

Answer 4

Detached entities exists only to minimize the time your data is locked due to a transaction, maximizing the number of simultaneous users. Of course, this comes with a cost, and you listed them. but since merging conflicts are usually rare, people accept some rare bugs.

You see, data conflics will always exist, but they occur less when the transaction is short :-)

Answer 5

For instance, suppose you have a RESTful interface with a method for retrieving an JSON-serialized object by its id to the caller and a method that receives an updated version of this object from the caller. An entity that passed through such serialization/deserialization will appear in a detached state.

check this, and read 3.3 merge

Answer 6

Detached - a detached instance is an object that has been persistent, but its Session has been closed. The reference to the object is still valid, of course, and the detached instance might even be modified in this state. A detached instance can be reattached to a new Session at a later point in time, making it (and all the modifications) persistent again. This feature enables a programming model for long running units of work that require user think-time. We call them application transactions, i.e., a unit of work from the point of view of the user.

References Hibernate DOc

Why?

The Session caches every object that is in a persistent state (watched and checked for dirty state by Hibernate). If you keep it open for a long time or simply load too much data, it will grow endlessly until you get an OutOfMemoryException. One solution is to call clear() and evict() to manage the Session cache,keeping a Session open for the duration of a user session also means a higher probability of stale data.

References Again Hibernate Doc

I bet you haven't read through hibernate documentation itself, It has scenarios explaining them too :)

Simple Explanation:With reference to persistent objects..

Suppose a user has to update a form, you get the details of user in from through UserObject, This user object is persistent with session. Now if user doesn't submit the form, your session is open until server session expires, how long will you wait? If you have used getCurrentSession, another form request comes while previous one is not submitted, you have got dirty data now!! What if your object is waiting for a data that is to come for a web-service and it taking long enough, will you still keep session open, object persistent with session?