I assume you are using Slf4j.
This library does not support that functionally out of the box.
The capacity of changing the logger level at runtime largely depends on the underlying logging libraries (Logback, Log4J2, etcetera) configured.
But Spring Boot provides an underlying logging system that handles all this stuff for us. We can use that underlying logging system to achieve the functionally that you need.
You can do something like the following example:
@Scheduled(cron = "${* * * * * *}")
public void task() {
// At the beginning of the method, disable logging levels
final List<String> loggerNames = Arrays.asList("org.hibernate.SQL", "org.hibernate.type", "org.hibernate.type.descriptor.sql.BasicBinder");
Map<String, LogLevel> previousLogLevels = new HashMap();
loggerNames.forEach(loggerName -> {
final LoggerConfiguration loggerConfiguration = loggingSystem.getLoggerConfiguration(loggerName);
final LogLevel logLevel = loggerConfiguration.getEffectiveLevel();
previousLogLevels.put(loggerName, logLevel);
loggingSystem.setLogLevel(loggerName, LogLevel.OFF);
});
try {
// Do your stuff
...
} finally {
// Restore the logging levels to the original ones
previousLogLevels.forEach((loggerName, logLevel) -> loggingSystem.setLogLevel(loggerName, logLevel));
}
}
You must inject a bean of type LoggingSystem in your scheduled task bean so you can reference it in the code.
This functionally can be easily reused in different contexts: if you need to, you can create an aspect for that, for instance, freeing the business logic from this need.
Edit
After read the @KavithakaranKanapathippillai answer, and read again, carefully, your question, I fully understand your need.
He is right: please, be aware that with this setup you will modify the logging level of the affected logs globally, not only for the async task, and the rest of the code will be also affected for the change, so it will be always a chance for lost some "normal" application code log traces if that "normal" code uses Hibernate and is executed while the async task is running.
If this is important or not will largely depend on how much the async task is running - I suppose it runs very fast if it is executed every second but, on the other hand, it runs a lot times - and how many transactions your application receives.
