SpringBatch Fix ORA-08177 error by changing isolationLevel

Question

Background: In our department, we have been migrating the COBOL jobs to SpringBatch jobs and the 1st SpringBatch job went live in Jan 2022. We were using SpringBoot 2.7.11 until last month when we upgraded to SpringBoot 3.2.5. We used the property "spring.batch.jdbc.table-prefix" to prefix the springbatch metadata tables for the upgrade because we didn't want to block the springbatch jobs of other departments that haven't upgraded yet.

Summary: After the upgrade, we started to see the ORA-08177 error intermittently from the batch_job_instance insert for few of the 10 jobs we have. Other jobs are running fine. We never had this error before the upgrade. But this error is not occurring consistently, so we're not able to reproduce this error. Sometimes, this error automatically goes off after a few unsuccessful attempts. After doing an extensive google search, we understand the SO user community suggest 3 different solutions for this error.

1. Creating the tables with SEGMENT CREATION IMMEDIATE(which we already followed when we upgraded)
2. Dummy row insert into 3 springbatch metadata tables (batch_job_instance, batch_job_execution, batch_job_execution_context)
3. Changing the isolationLevelForCreate to READ_COMMITTED

Though the dummy row inserts fixed the ORA error, our higher management wasn't convinced with this approach as this approach doesn't sound a permanent fix. So, we thought of implementing the 3rd option, changing the isolationLevelForCreate.

Questions: We managed to implement it by creating a new class, say BatchConfig, extending DefaultBatchConfiguration, annotated with @Configuration and overrode the "getIsolationLevelForCreate" method to return Isolation.READ_COMMITTED. We have couple of questions. Can someone please clarify?

UPDATE As expected, the automatic launch of jobs using the job name didn't work after using the DefaultBatchConfiguration. We managed to solve that using the CommandLineRunner. So, striking off all the questions except question # 1a and 2.

1. We created a new class, say BatchConfig, extending DefaultBatchConfiguration, annotated with @Configuration and overrode the "getIsolationLevelForCreate" method to return Isolation.READ_COMMITTED. Is this overriding alone enough to accomplish the purpose, which is to change the isolation level to READ_COMMITTED? Will this approach cause any other/new problem because SpringBoot 3.0 Migration guide says "@EnableBatchProcessing or DefaultBatchConfiguration is no longer required and should be removed from applications that want to use Boot’s auto-configuration" and using it will back off the auto-configuration of Spring Batch. With our implementation, what all features of SpringBatch are we going to miss out? Is there a way to get the SpringBatch's auto-configuration with the isolationLevelForCreate alone changed?

1a) And, we observed couple of things with this approach. In IntelliJ, WITHOUT the new BatchConfig class, we put a breakpoint in the DefaultBatchConfiguration's jobRepository method and started the server in debug mode. We noticed that the breakpoint occurred 4 times. But, WITH the new BatchConfig class, the breakpoint occurred only once. Is that expected (or) is there something brewing with our change?

1b) Also, WITH the new BatchConfig class, the log doesn't show the below 2 lines. The below 2 lines show up in the log WITHOUT the new BatchConfig class. Can you please clarify this as well?

o.s.w.s.FrameworkServlet: Initializing Servlet 'dispatcherServlet' 
o.s.w.s.FrameworkServlet: Completed initialization in XX ms.

2. How to confirm/prove/verify/show that the isolationLevel is indeed READ_COMMITTED after the override as there's nothing shown in the logs related to the isolation level?

Thanks in advance.