Calling `JobExplorer` outside of a transaction logs warnings about the isolation Level not being applied

[kzander91]

Not sure if this is a bug or just a documentation issue.

Bug description
As of Batch 5, calling any JobExplorer method without an active transaction produces the following warning:

2022-11-11T23:33:19.650Z  WARN o.s.jdbc.support.JdbcTransactionManager  : Custom isolation level specified but no actual transaction initiated; isolation level will effectively be ignored: PROPAGATION_SUPPORTS,ISOLATION_READ_COMMITTED

The cause seems to be the changes made with #4195. As of these changes, JobExplorer is transactional with PROPAGATION_SUPPORTS,ISOLATION_READ_COMMITTED, causing the warning being logged if called outside of a transaction.

Environment
Spring Batch 5.0.0-RC2

Steps to reproduce

1. Call any JobExplorer method without an active transaction.

Expected behavior
The call works without issuing warnings.

Minimal Complete Reproducible example
demo1.zip

1. Unzip
2. Run mvn spring-boot:run

The app calls JobExplorer#getJobInstanceCount() from a CommandLineRunner, which issues the warning mentioned above.

[hpoettker]

As far as I can tell, the warning is harmless, and can be ignored. But I think it should still be dealt with before Spring Batch 5 goes GA.

It really doesn't take much to trigger it:

@SpringBootApplication
public class DemoApplication {

  public static void main(String[] args) {
    SpringApplication.run(DemoApplication.class, args);
  }

  @Bean
  Job job(JobRepository jobRepository, Step step) {
    return new JobBuilder("job", jobRepository)
        .start(step)
        .incrementer(new RunIdIncrementer())
        .build();
  }

  @Bean
  Step step(JobRepository jobRepository, PlatformTransactionManager transactionManager) {
    return new StepBuilder("step", jobRepository)
        .tasklet((contribution, chunkContext) -> RepeatStatus.FINISHED, transactionManager)
        .build();
  }

}

Here, the RunIdIncrementer leads to a call of JobParametersBuilder::getNextJobParameters, which calls JobExplorer::getLastJobInstance.

[fmbenhassine]

@kzander91 Thank you for opening this issue. I think the current default propagation level SUPPORTS is correct, but not the default isolation level of READ_COMMITTED. This will be changed to DEFAULT, which fixes the issue.