The FastBootEntityManagerFactoryBuilder doesn't allow us to decorate the SessionFactory

[vladmihalcea]

Describe the bug

Hibernate Core provides the EntityManagerFactoryBuilderImpl so that when building an EntityManagerFactory, the SessionFactoryBuilder SPI is used, like this:

public EntityManagerFactory build() {
	SessionFactoryBuilder sfBuilder = metadata().getSessionFactoryBuilder();
	populate( sfBuilder, standardServiceRegistry );

	try {
		return sfBuilder.build();
	}
	catch (Exception e) {
		throw persistenceException( "Unable to build Hibernate SessionFactory", e );
	}
}

Quarkus does not do that. Instead, it creates a hardcoded SessionFactoryImpl in the FastBootEntityManagerFactoryBuilder, like this:

public EntityManagerFactory build() {
	try {
		SessionFactoryOptionsBuilder optionsBuilder = this.metadata.buildSessionFactoryOptionsBuilder();
		this.populate(this.persistenceUnitName, optionsBuilder, this.standardServiceRegistry);
		return new SessionFactoryImpl(this.metadata, optionsBuilder.buildOptions(), this.metadata.getTypeConfiguration().getMetadataBuildingContext().getBootstrapContext());
	} catch (Exception var2) {
		throw this.persistenceException("Unable to build Hibernate SessionFactory", var2);
	}
}

Expected behavior

The FastBootEntityManagerFactoryBuilder should use the SessionFactoryBuilder so that applications can decorate the Hibernate SessionFactory via this SPI mechanism.

Actual behavior

The SessionFactoryImpl is instantiated no matter if we declare a org.hibernate.boot.spi.SessionFactoryBuilderFactory SPI.

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @Sanne (hibernate-orm), @gsmet (hibernate-orm), @yrodiere (hibernate-orm)

[Sanne]

Hi @vladmihalcea , we don't necessarily support all SPI and integrations; we can consider this but I'm classifying it as a feature request.

Could you elaborate on why you need to decorate it?

[vladmihalcea]

@Sanne Thanks for the explanation. This is needed by the Quarkus clients who are also using Hypersistence Optimizer to detect performance issues automatically.

This problem has been reported by one of the users in this issue.

[Sanne]

Ic, thanks. But could you explain which aspect of the SessionFactoryBuilder you need?

We can't expose the SessionFactoryBuilder as-is as it allows several options which Quarkus sets/controls automatically, and really are a bit specific to runtime integrations so not really interesting to end users, but we can look into exposing particular observability hooks.

For example, if you need applyInterceptor we can allow that specifically; or that might be possible already in other ways (I'd have to look as I don't remember).

[vladmihalcea]

Hypersistence Optimizer uses the SessionFactoryBuilderFactory SPI so that it can replace the standard SessionFactory with a decorated one that analyzes how queries or entity state changes are done.

For this, it relies on the org.hibernate.boot.spi.SessionFactoryBuilderFactory SPI, which Hibernate can load and use to create a decorated SessionFactory, like Hibernate OGM used to do.

[adampoplawski]

Hello @Sanne @vladmihalcea
I am Hypersistence Optimizer user, I assume allowing decorating SessionFactory is not planned?

[vladmihalcea]

@adampoplawski It's unfortunate that Quarkus took the decision to not honor that SPI contract.

Hypersistence Optimizer can decorate Spring Boot just fine, and starting with version 2.8, it will support Micronout as well.

Therefore, until this issue is fixed, if you want to benefit from all the advantages offered by Hypersistence Optimizer, you can use Spring Boot or Micronout instead for your services.

[Vinche59]

@Sanne Any update on that request ?

[adampoplawski]

@Sanne Is this still considered? Maybe an option would be to allow this only to the dev/test profile?

[adampoplawski]

Hello @Sanne
So it seems from Quarkus point of view this Change Request won't be accepted?

[yrodiere]

Hello,

If by "accepted" you mean "someone from the Quarkus team will work on it", then I'm afraid it's unlikely as there are more pressing issues. Sanne himself is busy elsewhere these days.

If by "accepted" you mean "someone will have a look at a PR and merge it if it seems safe", then that's more likely.

It does seem possible to shoehorn something in here:

quarkus/extensions/hibernate-orm/runtime/src/main/java/io/quarkus/hibernate/orm/runtime/boot/FastBootEntityManagerFactoryBuilder.java

Lines 82 to 91 in 47ecd0a

	public EntityManagerFactory build() {
	try {
	final SessionFactoryOptionsBuilder optionsBuilder = metadata.buildSessionFactoryOptionsBuilder();
	populate(persistenceUnitName, optionsBuilder, standardServiceRegistry);
	return new SessionFactoryImpl(metadata, optionsBuilder.buildOptions(),
	metadata.getTypeConfiguration().getMetadataBuildingContext().getBootstrapContext());
	} catch (Exception e) {
	throw persistenceException("Unable to build Hibernate SessionFactory", e);
	}
	}

That would look more like Hibernate ORM at https://github.com/hibernate/hibernate-orm/blob/f0f96916adb5adbba56ed19f583343559d16576b/hibernate-core/src/main/java/org/hibernate/jpa/boot/internal/EntityManagerFactoryBuilderImpl.java#L1455

However, I'm pretty sure at least some (most?) of the SessionFactoryBuilderImplementor methods wouldn't work properly, and there is a chance this would create issues with native image generation (now-reachable codepaths causing native image generation failure).

So, it'll be work. It'll require testing. It'll require documenting limitations. But if someone feels strongly about it, they can give it a try.