java - example - JPA fusionar vs. persistir

jpa update entity

Question

Hasta ahora, mi preferencia ha sido utilizar siempre la merge() de EntityManager merge() para cuidar tanto de la inserción como de la actualización. Pero también he notado que la fusión realiza una consulta de selección adicional antes de la actualización / inserción para garantizar que el registro no exista en la base de datos.

Ahora que estoy trabajando en un proyecto que requiere inserciones extensas (a granel) en la base de datos. Desde el punto de vista del rendimiento, ¿tiene sentido usar persistir en lugar de fusionar en un escenario donde sé absolutamente que siempre estoy creando una nueva instancia de objetos para persistir?

Answer 1

Definitivamente iría con Persist persist() si, como dijiste:

(...) Sé que siempre estoy creando una nueva instancia de objetos para persistir (...)

De eso se trata este método: lo protegerá en los casos en que la Entidad ya exista (y revertirá su transacción).

Answer 2

No es una buena idea usar merge cuando una persist suficiente; la merge hace mucho más trabajo. El tema se ha discutido anteriormente en , y este artículo explica en detalle las diferencias, con algunos diagramas de flujo para aclarar las cosas.

Answer 3

Si está utilizando el generador asignado, usar merge lugar de persist puede provocar una instrucción SQL redundante , lo que afecta el rendimiento.

Además, la combinación de llamada para entidades administradas también es un error, ya que Hibernate administra las entidades administradas automáticamente y su estado se sincroniza con el registro de la base de datos mediante el mecanismo de comprobación sucia al enjuagar el Contexto de persistencia .

Para comprender cómo funciona todo esto, primero debe saber que Hibernate cambia la mentalidad del desarrollador de las declaraciones de SQL a las transiciones de estado de la entidad .

Una vez que Hibernate gestiona activamente una entidad, todos los cambios se propagarán automáticamente a la base de datos.

Hibernate monitorea las entidades adjuntas actualmente. Pero para que una entidad se administre, debe estar en el estado de entidad correcto.

Primero, debemos definir todos los estados de la entidad:

• Nuevo (Transitorio)

  Un objeto recién creado que no haya sido asociado con una Session Hibernación (también conocido como Persistence Context ) y que no esté mapeado en ninguna fila de la tabla de la base de datos se considera que está en el estado Nuevo (Transitorio).

  Para persistir necesitamos llamar explícitamente al método EntityManager#persist o hacer uso del mecanismo de persistencia transitiva.

• Persistente (Administrado)

  Una entidad persistente se ha asociado con una fila de tabla de base de datos y está siendo administrada por el contexto de persistencia en ejecución actual. Cualquier cambio realizado en dicha entidad se detectará y se propagará a la base de datos (durante el tiempo de descarga de la sesión). Con Hibernate, ya no tenemos que ejecutar instrucciones INSERT / UPDATE / DELETE. Hibernate emplea un estilo de trabajo transaccional de escritura retrasada y los cambios se sincronizan en el último momento responsable, durante el tiempo de actividad de la Session actual.

• Separado

  Una vez que se cierra el Contexto de Persistencia en ejecución actual, todas las entidades administradas previamente se separan. Los cambios sucesivos ya no se rastrearán y no habrá sincronización automática de la base de datos.

  Para asociar una entidad separada a una sesión de Hibernate activa, puede elegir una de las siguientes opciones:

  • Volver a unir

    Hibernate (pero no JPA 2.1) admite volver a conectar a través del método de actualización Session #. Una sesión de Hibernate solo puede asociar un objeto de entidad para una fila de base de datos dada. Esto se debe a que el Contexto de persistencia actúa como un caché en memoria (caché de primer nivel) y solo un valor (entidad) está asociado con una clave determinada (tipo de entidad e identificador de base de datos). Una entidad puede volverse a vincular solo si no hay otro objeto JVM (que coincida con la misma fila de la base de datos) ya asociado a la sesión de Hibernate actual.

  • Fusión

  La fusión va a copiar el estado de entidad separada (fuente) a una instancia de entidad gestionada (destino). Si la entidad fusionada no tiene equivalente en la sesión actual, se obtendrá uno de la base de datos. La instancia del objeto separado continuará estando desconectada incluso después de la operación de fusión.

• Remoto

  Aunque JPA exige que solo se permita eliminar entidades gestionadas, Hibernate también puede eliminar entidades separadas (pero solo a través de una llamada al método de eliminación de sesión #). Una entidad eliminada solo está programada para borrarse y la declaración DELETE de la base de datos real se ejecutará durante el tiempo de instalación de la sesión.

Para comprender mejor las transiciones de estado JPA, puede visualizar el siguiente diagrama:

O si usa la API específica de Hibernate: