What happens to dereferenced hibernate (JPA) entities?

Question

In a project i am working on, we have an EJB backend where various clients connect remotely (i.e. Web layer, web services layer, etc). The clients are on another machine and can be in another data center, so the front end and backend are never in the same app server.

The backend is layered as follows:

SLSB <-> Service Layer Objects <-> DAO

All objects are spring managed, except for the SLSB. The chain of events is as follows:

Initialization:

1. Entity Manager injected into DAO
2. DAO injected into Service Object
3. Service Object injected into SL EJB
4. SLSB's only provide a remote interface All objects are Singleton and stateless

Request/Response:

method invoked on EJB, delegates to Service Object, uses DAO's, return DTO

The DAO's encapsulate all the query operations on JPA entities. No JPA entity bleeds past the service layer. The service layer demarcates the transaction.

What happens to the JPA entities once the request/response lifecycle is complete with this architecture? Should the service layer attempt to cache the entities, or is that hibernates job?

And any comments on this architecture is welcome.

thanks

• Billworth

Answer 1

What happens to the JPA entities once the request/response lifecycle is complete with this architecture?

In the case of a container-managed persistence context that is TRANSACTION scoped, the persistence context ends when the associated JTA transaction commits or rolls back and all entities that were in the persistence context are detached. From the JPA specification:

5.6.1 Container-managed Transaction-scoped Persistence Context

The application may obtain a container-managed entity manager with transaction-scoped persistence context bound to the JTA transaction by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContextType.TRANSACTION.

A new persistence context begins when the container-managed entity manager is invoked^[36] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction.

The persistence context ends when the associated JTA transaction commits or rolls back, and all entities that were managed by the EntityManager become detached.

If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will immediately become detached at the end of the method call.

Detached entities will then be garbage collected if the application doesn't hold a reference anymore.

Should the service layer attempt to cache the entities, or is that hibernates job?

If you want to cache entities across various persistence contexts, aka second level (L2) caching, that's a job for the JPA provider. It is aware of the various persistence events and can interact appropriately with a cache. There is no point at implementing a similar mechanism at the service layer level when your JPA provider already offers this feature. For Hibernate, see 19.2. The Second Level Cache.