org.hibernate.jpa.spi.AbstractEntityManagerImpl.AfterCompletionActionImpl#doAction is where the JTA callback "chain" eventually clears the session.

I think only solution here currently will have to involve org.hibernate.jpa.spi.AbstractEntityManagerImpl.AfterCompletionActionImpl#doAction checking the current thread against the application thread (which means we'd have to keep that around here) and if there is a mismatch set a flag rather than immediately doing the clear.

From there we have 2 options to leverage that flag...

The first (not-too-invasive) option to address this would be to have org.hibernate.internal.SessionImpl#checkTransactionSynchStatus check that flag and if set, clear the session. org.hibernate.internal.SessionImpl#checkTransactionSynchStatus is a method already wired in to run at the start of most Session methods. The down side here is that the session might not get cleared in a timely manner as this really relies on the next time the Session/EM is invoked.

The other (better?) option is to handle this as a Session method exit process (whereas checkTransactionSynchStatus is a Session method entry process. In psuedo-code:

someSessionMethod() {
    errorIfClosed();
    checkTransactionSynchStatus();

    try {
        // real 'someSessionMethod' processing
    }
    finally {
        postOperationTransactionSynchHook();
    }
}

This is much more invasive as we'd have to alter most every method on Session to account for this.