2017-07-11 3 views
1

私は、4ノードがクォーツを使用してジョブをスケジュールする大きなアプリケーションを持っています。クォーツブロッキングオンアップデートの選択

は非常に頻繁に私たちのDBチームからのメールを取得しています

'QRTZ_LOCKS SELECT * FROMは、WHERE LOCK_NAME =' 'UPDATE FOR' TRIGGER_ACCESS

は、15〜20分間ブロックしていること。時には時間。 そして私の仕事はロックを待っているのが分かっています。

かなり古いバージョンのQuartz 1.8.3を使用しています。ここでは私が使用しているクォーツの設定は

org.quartz.scheduler.instanceName = DefaultQuartzScheduler 
org.quartz.scheduler.instanceId = AUTO 
org.quartz.scheduler.rmi.export = false 
org.quartz.scheduler.rmi.proxy = false 
org.quartz.scheduler.wrapJobExecutionInUserTransaction = false 

org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool 
org.quartz.threadPool.threadCount = 25 
org.quartz.threadPool.threadPriority = 5 
org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread = true 

org.quartz.jobStore.misfireThreshold = 60000 

org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreCMT 

org.quartz.jobStore.driverDelegateClass=com.xyx.abc.common.scheduler.impl.CDAJDBCDelegate 
org.quartz.jobStore.useProperties=false 
org.quartz.jobStore.tablePrefix=QRTZ_ 
org.quartz.jobStore.isClustered=true 
org.quartz.jobStore.clusterCheckinInterval = 20000 

# these 3 are required by customSchedulerFactory class 
org.quartz.dataSource.myDS.connectionProvider.class=com.xyz.abc.common.scheduler.impl.CustomPoolingConnectionProvider 
org.quartz.jobStore.dataSource=myDS 
org.quartz.jobStore.nonManagedTXDataSource=myDS 

私はQuartzのデバッグログを有効にしようとしました。しかし、それから多くを得ることはありませんでした。

誰も似たような問題に直面しましたか? 'Select for update'クエリが高速に実行されていることを確認するにはどうすればよいですか?

+0

SELECT FOR UPDATE問合せはQRTZ_LOCKS表の行をロックします。そのため、その表の同じ行に対して同時SELECT FOR UPDATE問合せがある場合、その並行問合せは最初のSELECT FOR UPDATE問合せでロックを解放するために待機します実行する前にコミットするかロールバックするかのいずれかを選択します。 – ivanzg

+0

@ivanzgと同意します。あなたはQuartzではなく、データベースのロックに関する問題を抱えているようです。 –

答えて

0

おそらくこれらのクエリは無視されます。

私はこの問題の反対側にいました。私は長期にわたるクエリを見つけて、Java開発者にそれを修正するよう依頼したデータベースチームの担当者でした。細部は覚えていませんが、なぜこのように働いたのか、また何も修正することはないということについての良い説明があったことを覚えています。

GV$SQL.ELAPSED_TIME降順でソートしたときにクエリが常に掲載結果レポートに表示されました。しかし、詳しい点検の結果、重要なリソースを使用していないことがわかりました。彼らはCPU、I/O、または他の貴重なリソースを使用していませんでした。 ELAPSED_TIMEの列が誤解を招くような珍しい時期です。

私はそれらを無視し、他のクエリについて心配していました。

関連する問題