Failure obtaining dB row lock exception occurs when quartz is integrated in spring.

Today, we use spring to integrate quartz for Task Scheduling in a new project. As in the past, we have configured jobdetail, trigger, and schedulerfactorybean to start, but encountered the following exception:
Org. springframework. Beans. Factory. beancreationexception: Error creating bean with name 'sfb' defined in URL [jar: file: //.../xxx-biz-service.jar! /Bean/spring-task.xml]: Invocation of init method failed; Nested exception is Org. quartz. schedulerconfigexception: Failure occured during job recovery. [See nested exception: Org. quartz. impl. jdbcjobstore. lockexception: Failure obtaining dB row lock: ORA-00942: Table or view does not exist <br/> [see nested exception: Java. SQL. sqlexception: ORA-00942: Table or view does not exist <br/>] <br/> caused by: <br/> Org. quartz. schedulerconfigexception: Failure occured during job recovery. [See nested exception: Org. quartz. impl. jdbcjobstore. lockexception: Failure obtaining dB row lock: ORA-00942: Table or view does not exist <br/> [see nested exception: Java. SQL. sqlexception: ORA-00942: Table or view does not exist <br/>] <br/> at Org. quartz. impl. jdbcjobstore. jobstoresupport. initialize (jobstoresupport. java: 493) <br/> at Org. quartz. impl. jdbcjobstore. jobstorecmt. initialize (jobstorecmt. java: 144) <br/> at Org. springframework. scheduling. quartz. localperformancejobstore. initialize (localperformancejobstore. java: 133) <br/> at Org. quartz. impl. stdschedulerfactory. instantiate (stdschedulerfactory. java: 1010) <br/> at Org. quartz. impl. stdschedulerfactory. getschedfactory (stdschedulerfactory. java: 1152) <br/> at Org. springframework. scheduling. quartz. schedulerfactorybean. createschedbean (schedulerfactorybean. java: 668) <br/> at Org. springframework. scheduling. quartz. schedulerfactorybean. afterpropertiesset (schedulerfactorybean. java: 568) <br/> at Org. springframework. beans. factory. support. abstractautowirecapablebeanfactory. invokeinitmethods (abstractautowirecapablebeanfactory. java: 1057) <br/> at Org. springframework. beans. factory. support. abstractautowirecapablebeanfactory. initializebean (abstractautowirecapablebeanfactory. java: 1024) <br/> at Org. springframework. beans. factory. support. abstractautowirecapablebeanfactory. createbean (abstractautowirecapablebeanfactory. java: 421) <br/> at Org. springframework. beans. factory. support. abstractbeanfactory $1. getObject (abstractbeanfactory. java: 245) <br/> at Org. springframework. beans. factory. support. defaultsingletonbeanregistry. getsingleton (defaultsingletonbeanregistry. java: 140) <br/> at Org. springframework. beans. factory. support. abstractbeanfactory. getbean (abstractbeanfactory. java: 242) <br/> at Org. springframework. beans. factory. support. abstractbeanfactory. getbean (abstractbeanfactory. java: 156) <br/> at Org. springframework. beans. factory. support. defaultlistablebeanfactory. preinstantiatesingletons (defaultlistablebeanfactory. java: 270) <br/> at Org. springframework. context. support. abstractapplicationcontext. refresh (abstractapplicationcontext. java: 346) <br/> at Org. springframework. context. support. classpathxmlapplicationcontext. <init> (classpathxmlapplicationcontext. java: 92) <br/> at Org. springframework. context. support. classpathxmlapplicationcontext. <init> (classpathxmlapplicationcontext. java: 77)

This is a very strange error. From the printed exception information, we can see that quartz is trying to make the task execution persistent to the database, generally, it is a method used in the Cluster Environment to synchronize tasks, so that only one machine in the cluster can execute scheduled tasks at a certain time point.
However, I am surprised that, first, I have not configured the quartz data source information; second, I have not configured the quartz cluster, and quartz should only maintain the task list in the memory. Because we have no custom quartz. properties at all.

From the log, this is indeed an exception thrown by quartz, and a problem occurs during schedulerfactorybean. createscheduler. You can directly view the source code of schedulerfactorybean and be surprised to find the datasource attribute !! In addition, the setdatasource method annotation shows that this attribute will overwrite the datasource configured in the quartz. properties file. When we see this attribute, everything is clear. It turns out to be a disaster caused by spring's automatic injection! I have encountered similar incidents some time ago. For details, refer to "online shop version rebirth series: All faults caused by automatic injection in spring configuration";

Generally, the beanid of our data source is datasource, so spring is smart again when spring is automatically injected! Solution 2: first, cancel the automatic injection of the bean where the quartz job-related configuration is located. Note: you do not need to automatically inject all the spring configuration files to Western Europe. Second: rename the beanid of the system data source datasource;