在不同的线程上运行时，Hibernate不必要地创建新实体

Question

I am using Spring Data JPA, running the following test results in counter-intuitive behavior

@Test
public void testAsync() throws ExecutionException, InterruptedException {
    Job job = jobRepository.save(new Job());
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setCorePoolSize(10);
    long origJobID = job.getId();
    executor.initialize();
    Future<?> wait = executor.submit(() -> {
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        Job outcome = jobRepository.save(job.setStopTime(Instant.now()));
        // this assertion fails, Hibernate requested a new ID and persisted a new entity ... even though I am reusing the same instance with an ID already populated
        assertEquals(origJobID, outcome.getId().longValue());
    });
    wait.get();
}

Since jobRepository only provide a save() interface, as a user I of the service I can only call this method to INSERT or UPDATE my entity ... how is it possible that the underlying entity manager just ignore the fact that my entity already has an ID and goes ahead and creates a duplicate row?

Looking further into Hibernate's codebase, it appears on a new Thread, the persistentContext is wiped clean. Therefore my entity is turned into a DETACHED state as far as the DefaultMergeEventListener is concerned ... creating a cascade of decisions that inexplicably leading to the generation of a new ID

The specific code I reference is located at: https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/event/internal/DefaultMergeEventListener.java#L109

If run from a new Thread, Hibernate's persistence context is empty ... which is fine .... but then I don't understand why is my entity now considered DETACHED ...

More excerpt from Hibernate's source code: Default https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/event/internal/DefaultMergeEventListener.java#L293

if ( result == null ) {
            //TODO: we should throw an exception if we really *know* for sure
            //      that this is a detached instance, rather than just assuming
            //throw new StaleObjectStateException(entityName, id);

            // we got here because we assumed that an instance
            // with an assigned id was detached, when it was
            // really persistent
            entityIsTransient( event, copyCache );
        }

EDIT If this is related to the fact that the transactions are not committed yet, and the new thread does not use the same transaction ... is there a way to force a transaction in code?

Note calling JpaRepository.saveAndFlush() does not resolve the issue

EDIT 2 I am using embedded h2 for this test, in either case, I expected saveAndFlush() to have committed the transaction to the database (embedded or on the other side of the world) so that multiple threads can use the JpaRepository to view the states saved by the other Threads right?

EDIT 3 Looking at other similar questions, it appears marking the test method itself as @Transaction(propagation = NOT_SUPPORTED) forces the underlying transaction manager to commit upon JpaRepository.save() ... this is still confusing ... how was the test method transactional to begin with? ie why did the transaction not commit to begin with?

Answer 1

A very rough idea of how it works:

• You have multiple threads
• Transactions are typically thread-bound (each thread gets its own transaction)
• EntityManager s are typically transaction-bound (each transaction has its own EntityManager , which sees things according to that transaction)

What you are doing is

1. Tell the entity manager in thread 1 that you want to make entity A persistent / save its changes (that is what save() means in Spring Data)
2. Pass entity A to thread 2
3. Tell the entity manager in thread 2 that you want to make entity A persistent / save its changes

As the entity managers are in different transactions and thread 1 has not committed its transaction when 3. is executed, from the point of view of thread 2 entity A is not yet persistent; so it will interpret save() (or saveAndFlush() ) as "make entity A persistent" and not as "save changes in entity A". And making entity A persistent implies assigning a new ID to entity A if necessary.

You should be able to make this work by ensuring that thread 1 has already committed when step 3. is executed. Anyway I do not recommend passing managed entity references between threads as it gets tricky really fast.

About Spring Data transaction demarcation, you can read https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#transactions for more information, but it basically involves making each transaction a method and then annotating that method.