CODEWITHSUNDEEP
jpajakarta-eeentity
naftalimich
naftalimich

Reputation: 411

How are state changes to JPA entities actually tracked

When I java.persistence.EntityManger.find() an @Entity the EntityManager checks the Transaction for an existing instance of its associated persistence context. If one exists, then

  1. if the entity being searched for is present in the context, then that is what is returned to the caller of EntityManager.find
  2. if the entity being searched for is not present in the context, then EntityManager gets it from the datasource and puts it there, and then that is what is returned to the caller of EntityManager.Find

And if the transaction does not contain an existing instance of the manager's associated persistence context, then the manage creates one, associates it with the transaction, finds the entity in the datasource, and adds it to that context for management, and then returns that entity to the caller of find.

--> the result is the same in that the caller now has a an managed entity that exists in the persistence context. (important: the persistent context is attached to the transaction, so if the transaction has ended at the point at which the client gets hold of the 'managed' entity, well then the persistence context is no more and the entity is 'detached' an no longer managed).

Now, when I make state changes using setters or other other internal state changing methods on my @entity instance, those changes are tracked because my entity is part of persistence context that will get flushed to the datasource when the transaction finally commits. My question is HOW are the state changes tracked and by what? If I were making the changes via some intermediary object, then that intermediary object could update the persistence context accordingly, but I'm not (or am I?). I'm making the changes directly using my @entity annotated object. So how are these changes being tracked.

Perhaps there are events that are being listened for? Listened for by what? I'm reading books and articles on the subject, but I can't pin this one point down.

Upvotes: 3

Views: 1182

Answers (1)

Ricardo Gusmão
Ricardo Gusmão

Reputation: 104

State changes are tracked by jpa vendor's internal implementation during entity's lifecycle.

Dirty checking strategy is vendor specific. Can be done by fields comparing or bytecode enhancements like posted in JPA dirty checking.

Although it's vendor specific, the PersistentContext will be aware of the state changes during state synchronization, on flush or on commit.

It's important to remember all the points where flushes can be done :

  • Manually
  • Before querying
  • Before commit

Upvotes: 3

Related Questions