Prevent early EntityManager access to avoid conflicts with Hibernate-native multi-tenancy

[mnnayeck]

I have configured Hibernate's native multitenancy in the attached persistence-tenant.txt.
As you can see:

<property name="hibernate.multiTenancy" value="DATABASE" /> <property name="hibernate.multi_tenant_connection_provider" value="mu.maccs.ffa.dao.spi.MultiTenantConnectionProviderImpl" /> <property name="hibernate.tenant_identifier_resolver" value="mu.maccs.ffa.dao.spi.MultiTenantIdentifierResolverImpl" />

I am using a simple JPARepository class as attached.

The problem is that on bootstrapping, org.springframework.data.jpa.repository.support.JpaRepositoryFactory's constructor makes the following call:
this.extractor = PersistenceProvider.fromEntityManager(entityManager);

which actually creates a hibernate sessionImpl to determine the PersistenceProvider to use in the JPARepository.

This is wrong because since my application is not executing any database call on boot, a Hibernate session creation is FORCED (which in turns creates a connection with the underlying datasource for that particular tenant). This line is the culprit:
Class<?> entityManagerType = em.getDelegate().getClass();

Because of this, I am forced to set a default tenantIdentifier in MultiTenantIdentifierResolverImpl which isn't right. There should be NO tenant resolution on creation of JpaRepositoryFactory.
persistence-tenant.txt
UserRepository.txt
MultiTenantConnectionProviderImpl.txt
MultiTenantIdentifierResolverImpl.txt

Log Trace:

2024-04-13 00:19:20,870 [main] TRACE org.springframework.beans.factory.support.DefaultListableBeanFactory.invokeInitMethods:1831 - Invoking afterPropertiesSet() on bean with name 'userRepository'
2024-04-13 00:19:20,884 [main] TRACE org.springframework.core.io.support.SpringFactoriesLoader.load:202 - Loaded [org.springframework.data.util.CustomCollectionRegistrar] names: [org.springframework.data.util.CustomCollections.VavrCollections, org.springframework.data.util.CustomCollections.EclipseCollections]
2024-04-13 00:19:37,009 [main] DEBUG org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke:310 - Creating new EntityManager for shared EntityManager invocation
2024-04-13 00:19:37,183 [main] TRACE org.hibernate.internal.SessionFactoryImpl$SessionBuilderImpl.openSession:1363 - Opening Hibernate Session.  tenant=root
2024-04-13 00:19:39,034 [main] TRACE org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService:234 - Initializing service [role=org.hibernate.stat.spi.StatisticsImplementor]
2024-04-13 00:19:39,446 [main] TRACE org.hibernate.internal.SessionImpl.<init>:272 - Opened Session [23989d6b-324a-4a3d-b4f2-3a358f5ff536] at timestamp: 1712953179446
2024-04-13 00:19:41,112 [main] TRACE org.hibernate.internal.SessionImpl.closeWithoutOpenChecks:396 - Closing session [23989d6b-324a-4a3d-b4f2-3a358f5ff536]
2024-04-13 00:19:41,117 [main] TRACE org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.close:152 - Closing JDBC container [org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl@67c020c8]
2024-04-13 00:19:41,123 [main] TRACE org.hibernate.resource.jdbc.internal.ResourceRegistryStandardImpl.releaseResources:329 - Releasing JDBC resources
2024-04-13 00:19:41,133 [main] TRACE org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.close:256 - Closing logical connection
2024-04-13 00:19:41,139 [main] TRACE org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.close:263 - Logical connection closed
2024-04-13 00:19:41,146 [main] DEBUG org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke:310 - Creating new EntityManager for shared EntityManager invocation
2024-04-13 00:19:41,151 [main] TRACE org.hibernate.internal.SessionFactoryImpl$SessionBuilderImpl.openSession:1363 - Opening Hibernate Session.  tenant=root
2024-04-13 00:19:41,160 [main] TRACE org.hibernate.internal.SessionImpl.<init>:272 - Opened Session [52517467-b3ab-49aa-8efb-832f41f21f60] at timestamp: 1712953181160
2024-04-13 00:19:41,166 [main] TRACE org.hibernate.internal.SessionImpl.closeWithoutOpenChecks:396 - Closing session [52517467-b3ab-49aa-8efb-832f41f21f60]
2024-04-13 00:19:41,172 [main] TRACE org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.close:152 - Closing JDBC container [org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl@66464f27]
2024-04-13 00:19:41,177 [main] TRACE org.hibernate.resource.jdbc.internal.ResourceRegistryStandardImpl.releaseResources:329 - Releasing JDBC resources
2024-04-13 00:19:41,182 [main] TRACE org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.close:256 - Closing logical connection
2024-04-13 00:19:41,189 [main] TRACE org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.close:263 - Logical connection closed

[mp911de]

JpaRepositoryFactory isn't tied to multi-tenancy identifiers. Upon application startup we need to obtain the EntityManager for various initialization tasks, verification of queries and introspection of managed types to properly start up the repository infrastructure.

At some point, this has to happen. Since repositories aren't tied to tenant information, what would be an alternative?

[mnnayeck]

I understand and agree with your point. I just think there must be another way to retrieve the extractor
The line causing problem at his point is
Class<?> entityManagerType = em.getDelegate().getClass();
which actually makes a connection to the database (which forces the developer to specify a tenant identifier for the connection to be successful to the datasource).

[mp911de]

Since you're already looking into the issue, care to investigate an approach that would work for you?

[odrotbohm]

I briefly thought about switching to checking the EMF for its type rather than the delegate, but it turns out both Hibernate's implementation of ….getEntityManagerFactory() and ….getDelegate() call checkOpen(). I am assuming that that call is triggering the opening of a connection, as getDelegate() simply returns this.

To me there are two aspects to this:

1. Unless there's a way for us to detect the actual JPA persistence provider from an EntityManager instance, it's gonna be hard for us to fix the problem. We could inspect Spring configuration setup, but that would couple our detection logic to more to expecting developers to set up their JPA infrastructure through it. While that's probably given for most of our user base, it might not be the case for all.
2. If we were able to delay the call to the EntityManager in the constructor of the repository factory, would that really help? As Mark pointed out, at some point we will have to interact with the EntityManager to validate queries. If any of those steps requires a connection to be established (I don't know whether that's true or not) you'd still have to answer the question of how to obtain a tenant identifier from the initialization process in general. How would you like to provide that?

We could still give the EMF inspection a try though as Spring wraps the EM into a proxy that delegates calls to getEntityManagerFactory() to return the Spring-managed EMF directly.

[mnnayeck]

Hello Olivier,

Regarding the second point, I don't think you can the call to the EntityManager. This means that you would need to delay it until the first call to the persistence layer done by the application.

Regarding your first point, the problem is getDelegate() which is implementation specific. I checked for Hibernate and EclipseLink - both call checkOpen() to simply open a connection before returning 'this'.

Hibernate:
@Override public Object getDelegate() { checkOpen(); return this; }

EclipseLink:
@Override public Object getDelegate() { try { verifyOpen(); return this; } catch (RuntimeException e) { setRollbackOnly(); throw e; } }

Honestly, I think we need to update the JPA spec to add em.getDelegateClass() method. This would be much much cleaner.

[mnnayeck]

I briefly tried to use em.getMetaModel() to try resolve the issue. but those also make a call to checkOpen() - both in EclipseLink as well as Hibernate. That's a dead end.

[mp911de]

For the time being we do not have a workaround that would work reliably, hence closing that ticket as it isn't actionable.

[ari-spf]

@mp911de what about using the EntityManagerFactory instead of the EntityManager to avoid requesting a tenant?

I'm imagining something like this: tenantive-idea.patch

edit: code is not fully formatted, but at least tests pass

If you guys agree with the idea, I can try to put together a PR.

[ari-spf]

The reasoning for my above idea is based on the fact that the proxy that Spring injects for the EntityManager does not get initialized upon calling the getEntityManagerFactory method:

[ari-spf]

@mp911de @odrotbohm: I've submitted a PR #3885
I'd appreciate if you can take a look

[mp911de]

We can delay EntityManager access when determining PersistenceProvider. However, for named query lookup and query validation of methods annotated with @Query, you we still run into EntityManager access that we cannot disable. Especially with Hibernate, looking up a named query is quite an adventure because Hibernate doesn't stick to EntityManagerFactory.getNamedQueries(Class) semantics regarding type assignability, rather they check the exact type and for subclasses of a query, that lookup cannot be easily done.

In any case, #3885 helps with reducing early access.