Menu
See this question.
It turns out that even without committing the transaction manually, before the TX is committed, the person has an ID after calling the save() method.
Isn't the database responsible of assinging the ID field? If so, how can the ID field be filled before commit? Does any communication with the DB occur before the TX is committed?
690
To find entity by their ID, we use the EntityManager. find() method and pass the entity class and the entity ID as the parameters.
If your object does not have an id, but its table does, this is fine. Make the object an Embeddable object, embeddable objects do not have ids. You will need a Entity that contains this Embeddable to persist and query it.
JPA and Hibernate transaction management Once a JPA transaction has started, any entity bean that interacts with the EnityManager -- be it through a persist, merge or delete method call -- will have its state managed by Hibernate until the transaction commits.
getTransaction(). commit - It marks the end of transaction and saves all the chnages with in the transaction into the database and it can't be rolled back.
Yes, the JPA is allowed to communicate with the DB before transaction commit. It can occur i.e. when you explicitly invoke EntityManager#flush().
Moreover, the JPA provider is allowed to do the flush operation whenever it feels it's necessary. However, by the convenience, JPA providers delays DB operations to the time the transaction will be committed.
Some automatic ID generator strategies must hit the database to get the PK value (as far as I remember the IDENTITY strategy works that way).
As a contrary, the TABLE or SEQUENCE generators don't necessary need to hit the DB to get the ID value. They use the allocationSize parameter to ask the DB TABLE or SEQUENCE for a batch of IDs that will be given to new entities without further communication with the database.
189
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
