Using native Hibernate multitenancy with Spring Data JPA breaks on application boot. about spring-data-jpa

[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.