Cuando Hibernate vacía una sesión, ¿cómo decide qué objetos de la sesión están sucios?

Question

Mi comprensión de Hibernate es que los objetos que se cargan desde el DB se agregan a la sesión. En varios puntos, dependiendo de su configuración, la sesión se vacía. En este punto, los objetos modificados se escriben en la base de datos.

¿Cómo decide Hibernate qué objetos están "sucios" y necesitan ser escritos?

¿Los proxies generados por las asignaciones de intercepción de Hibernate a los campos, y agregan el objeto a una lista sucia en la sesión?

¿Hibernate observa cada objeto de la Sesión y lo compara con el estado original del objeto?

¿O algo completamente diferente?

Answer 1

Hibernate hace/puede usar la generación de bytecode (CGLIB) para que sepa que un campo está sucio tan pronto como llame al setter (o incluso asigne el campo afaict).

Esto inmediatamente marca ese campo/objeto como sucio, pero no reduce la cantidad de objetos que deben revisarse con suciedad durante el lavado. Todo lo que hace es impactar la implementación de org.hibernate.engine.EntityEntry.requiresDirtyCheck(). Es todavía hace una comparación de campo por campo para comprobar la suciedad.

Digo lo anterior sobre la base de una red de arrastre reciente a través del código fuente (3.2.6GA), con la credibilidad que se agrega. Los puntos de interés son:

• SessionImpl.flush() desencadena un evento onFlush().
• SessionImpl.list() llamadas autoFlushIfRequired() que activan un evento onAutoFlush(). (en las tablas de interés). Es decir, las consultas pueden invocar un color. Curiosamente, no se produce una descarga si no hay ninguna transacción.
• Ambos eventos finalmente terminan en AbstractFlushingEventListener.flushEverythingToExecutions(), que termina (entre otras ubicaciones interesantes) en flushEntities().
• Ese bucles sobre cada entidad en la sesión (source.getPersistenceContext().getEntityEntries()) llamando al DefaultFlushEntityEventListener.onFlushEntity().
• Eventualmente terminará en dirtyCheck(). Ese método hace algunas optimizaciones wrt a CGLIB banderas sucias, pero todavía hemos terminado bucle sobre cada entidad.

Answer 2

Hibernate toma una instantánea del estado de cada objeto que se carga en la sesión. En color, cada objeto en la sesión se compara con su instantánea correspondiente para determinar cuáles están sucios. Las sentencias de SQL se emiten según sea necesario y las instantáneas se actualizan para reflejar el estado de los objetos de sesión (ahora limpios).

Answer 3

Echa un vistazo a org.hibernate.event.def.DefaultFlushEntityEventListener.dirtyCheck Cada elemento en la sesión va a este método para determinar si está sucio o no mediante la comparación con una versión intacta (uno de la caché o uno de la base de datos).

Answer 4

Hibernate default dirty checking mechanism recorrerá las entidades adjuntas actuales y unirá todas las propiedades con sus valores iniciales de tiempo de carga.

Puede visualizar mejor este proceso en el siguiente diagrama:

Answer 5

Estas respuestas son incompletas (en el mejor - no soy un experto aquí). Si tiene una entidad hib man en su sesión, no tiene NADA, aún puede obtener una actualización cuando llama a save() en ella. cuando? cuando otra sesión actualiza ese objeto entre su load() y save(). aquí está mi ejemplo de esto: hibernate sets dirty flag (and issues update) even though client did not change value