La pregunta SCBCD del día: EntityManager.flush()

(Imagen: Paul Césanne - Muchacha al piano)

La primera del día (hoy se vienen muchas):

A developer is modifying an existing Java EE application that uses the JDBC API to access the database. This code must be used but cannot be changed, and new code needs to be added that uses the Java Persistence API.

Both parts of the code will execute in the same JTA transaction.

Which method of the EntityManager interface should the new code use to ensure that the data read by JDBC statements includes the state of managed entities?

• Call refresh on each changed entity
  
• Call flush at the end of each business  method
  
• Call find before accessing any managed entity
  
• Call  lock at the beginning of each business method
  

Cuando llamamos a persist(), merge (), o remove(), estos cambios no se sincronizan con la base de datos hasta que el EntityManager decida confirmarlos. Podemos forzar la sincronización en cualquier momento llamando a flush() en el EntityManager, de modo que los cambios realizados ya pasen a la BD. Por defecto, se invoca a flush antes que se ejecute una query relacionada con los cambios y al momento de realizar commit en una transacción.

Regresando a la pregunta, nuestro código JPA y el código JDBC legacy se ejecutan en la misma transacción; por lo que existe la posibilidad de que los cambios realizados por el código JPA no estén confirmados en BD al momento de ejecutar el código JDBC, lo que nos llevaría a sucesos impredecibles e indeseables. Para evitar esto, mejor llamamos a flush después de cada método JPA, de modo que los cambios ya estén en BD al momento de ejecutar el código JDBC.

Por lo expuesto, la respuesta correcta sería la segunda. 

Pregunta tomada de ExamWorx