What's the reason for disabling schema refresh here? And why is there the need to declare and catch exceptions?

The goal here is to disable schema refresh before applying user-provided schema actions. Datastax4 waits for schema refresh after applying changes and if you're applying multiple it's really slow.

Regarding catching and declaring exceptions: it's a little messy because while performSchemaAction here doesn't throw any exceptions, SessionFactoryFactoryBean#performSchemaAction throws Exception and I want to re-use the code to disable and re-enable schema metadata. That requires me to use a ThrowingRunnable (instead of a Runnable) which means that the entire SchemaRefreshUtils.withDisabledSchema method now needs to declare that it throws an Exception. We know that it will never throw a checked exception for CqlSessionFactoryBean but it may throw an unchecked one, so we re-throw any unchecked RuntimeException while wrapping impossible checked exceptions with IllegalStateException just to get the code to compile without propagating throws Exception up the call stack.

The alternative is to use a Runnable instead of ThrowingRunnable in SessionFactoryFactoryBean#performSchemaAction which would mean that #withDisabledSchema doesn't throw any exceptions, but then in SessionFactoryFactoryBean we need to wrap checked exceptions thrown in our performSchemaActions call with RuntimeException to match the Runnable signature.

So yeah a bit of a mess either way. I looked into removing the throws Exception from SessionFactoryFactoryBean#performSchemaAction for a bit but it comes from the AbstractFactoryBean#getObject signature (that's called inside performSchemaAction) so a little difficult.

I see. We can revisit exceptions in performSchemaAction to remove any unnecessary exceptions.

The goal here is to disable schema refresh before applying user-provided schema actions. Datastax4 waits for schema refresh after applying changes and if you're applying multiple it's really slow.

We should leave schema refresh up to the config. If schema refresh is disabled as per config, we don't need to disable it on our side.

We should leave schema refresh up to the config

for anyone looking at this thread in the future: my impression based on what you said is that we should rely only on schema being disabled via config in performSchemaAction, but I see you added setSuspendLifecycleSchemaRefresh and I'm a big fan!

Why is the refresh for the actual session removed?

It actually happens inside SchemaRefreshUtils.withDisabledSchema. It isn't obvious from the PR itself, but from the javadoc of session.setSchemaMetadataEnabled:

If calling this method re-enables the metadata (that is, #isSchemaMetadataEnabled() was false before, and becomes true as a result of the call), a refresh is also triggered.

In other words, if schema refresh becomes re-enabled as a result then a refresh will be triggered.

There is one difference though - previously we'd call refreshSchema which is sync and blocking while the schema refresh here is more equivalent to calling Session#refreshSchemaAsync and discarding the returned CompletionStage. I could update the new code here to wait on the returned future but I don't think it's necessary, let me know if you think otherwise!

The schema refresh in SessionFactoryFactoryBean should be guarded as well.

I believe that's already tackled in this PR, let me know if I missed something!