¿La reversión de una transacción Hibernate elimina las entidades ed "session.flush()"?

Question

Me han confundido acerca de transaction.rollback. Aquí está el pseudocódigo de ejemplo:

transaction = session.beginTransaction()  
EntityA a = new EntityA();  
session.save(a);  
session.flush();  
transaction.rollback(); 

¿Qué sucede cuando funciona este código? ¿Tengo la entidad en la base de datos o no?

Answer 1

Respuesta corta: No, no tendrá entidad en la base de datos.

Respuesta más larga: hibernate es lo suficientemente inteligente como para no enviar inserciones/actualizaciones al DB hasta que sepa si la transacción se va a comprometer o revertir (aunque este comportamiento puede cambiarse configurando un FlushMode diferente) en su caso de invocar flush está forzando que se envíe el SQL al DB pero aún tiene la transacción DB para protegerlo, cuando llame al rollback, la transacción DB se retrotraerá eliminando los cambios realizados dentro de él y, por lo tanto, nada se guardará realmente . Tenga en cuenta que, dependiendo de su nivel de aislamiento de transacción configurado, tal vez otras transacciones puedan ver de alguna manera la Entidad A que guardó por un tiempo breve entre la operación de guardar y la reversión. También tenga en cuenta que el color se invoca automáticamente cuando intenta leer de DB, en el 99% de los casos que lo llama explícitamente no es necesario. Una excepción que viene a la mente es cuando se prueban unidades con pruebas de autodesplazamiento.

Answer 2

Cuando llama al session.save(a), Hibernate recuerda básicamente en algún lugar dentro de la sesión que este objeto debe ser guardado. Puede decidir si desea emitir INSERT INTO... inmediatamente, algún tiempo después o en la confirmación. Esta es una mejora en el rendimiento, que permite a Hibernate insertar por lotes o evitarlos si la transacción se retrotrae.

Cuando llama al session.flush(), Hibernate se ve forzado a emitir INSERT INTO... en la base de datos. La entidad se almacena en la base de datos, pero aún no se ha comprometido. Dependiendo del nivel de aislamiento de la transacción, no será visto por otras transacciones en ejecución. Pero ahora la base de datos sabe sobre el registro.

Cuando llama al transaction.rollback(), Hibernate retrocede la transacción de la base de datos. La base de datos maneja la reversión, eliminando así el objeto recién creado.

Considere ahora el escenario sin flush(). En primer lugar, nunca toca la base de datos por lo que el rendimiento es mejor y la reversión es básicamente una operación no operativa. Por otro lado, si el nivel de aislamiento de transacción es READ UNCOMMITTED, otras transacciones pueden ver el registro insertado incluso antes de la confirmación/restitución. Sin flush(), esto no sucederá, a menos que Hibernate no decida flush() implícitamente.

Answer 3

Creo que se confunde con flush y commit.

flush() sincroniza el estado con la base de datos, pero no está haciendo una confirmación. El estado sigue siendo visible por transacción, por lo que puede llamar al rollback para deshacer.

Así que la respuesta a su pregunta es: no, usted no tiene la entidad (a) en la base de datos.