Announcement Announcement Module
Collapse
No announcement yet.
Spring's default opposed to Quartz recommendation Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring's default opposed to Quartz recommendation

    I'm seeing triggers stuck in the ACQUIRED state, or other weird data problems.

    Spring defaults the Quartz property "org.quartz.jobStore.dontSetAutoCommitFalse" to "true" - which means Quartz will not turn off auto-commit mode on the database connections that it uses. This is the opposite of Quartz's own default for this setting. If your connection is defaulting to have auto-commit on, then you'll run into all sorts of strange problems relating to data inconsistencies -- the most common symptom being triggers that are "stuck" in the "ACQUIRED" state. Fix this by explicitly setting the property to "false".
    How is Spring doing this? By harcoding it on LocalDataSourceJobStore initialize() method
    Code:
    setDontSetAutoCommitFalse(true);
    As stated on Quartz documentation (see quote above) TRUE is the opposite of the recommendation. And furthermore, because of this, setting Quartz property "org.quartz.jobStore.dontSetAutoCommitFalse" differently does NOT have any effect.

    Unfortunately, the fix doesn't seem to be as easy as stated because, as I just mentioned, setting the property to a different value doesn't have any effect since it's being neglected when Spring set's it to TRUE.

    So, in order to re-enable this property to allow for configuration I needed to:
    1. Override LocalDataSourceJobStore and omit setDontSetAutoCommitFalse(true).
    2. Override SchedulerFactoryBean to use my version of LocalDataSourceJobStore. Why? Well, becasue LocalDataSourceJobStore is also harcoded in SchedulerFactoryBean.
    Code:
    mergedProps.put(StdSchedulerFactory.PROP_JOB_STORE_CLASS, LocalDataSourceJobStore.class.getName());
    3. Override LocalTaskExecutorThreadPool, ResourceLoaderClassLoadHelper, SchedulerAccessorBean, SchedulerAccessor. Why? because they all have static references to one of the components I needed to override.

    Conclusion:
    a. Using Spring's Quartz support out of the box sets org.quartz.jobStore.dontSetAutoCommitFalse to the opposite value recommended by Quartz.
    b. It is not possible, using Spring's Quartz out of the box support, to change the property and set it to Quartz recommendation (false).
    c. To re-enable this property I need to override 6 Spring components. Note: I did tried to minimize the re-work by extending and override only needed methods but it got very messy quiet fast so I opted for overriding whole classes and just changing the lines and references that needed change.

    My questions to the experts:
    1. What are the reasons/motivations to harcode setDontSetAutoCommitFalse vs being configurable as is Quartz way?
    2. Why is it being set to TRUE which is the opposite of Quartz recommendation?
    3. Why is the JobStore also hardcoded to LocalDataSourceJobStore in SchedulerFactoryBean vs being configurable as is Quartz way?


    Am I missing something here? Because I find troublesome having to override 6 third party components in order to "re-enable" a property that should be enabled out of the box. I also, at the moment, don't understand why Spring chose to set it to the opposite of Quartz recommendation.

    I would really like to hear some opinions and get some answers to the above questions. So, please feel free to comment and if you had gone through the same please drop a few lines sharing your experience and how you got around this issue.


    Thanks,


    nicolas.loriente
    Last edited by nicolas.loriente; Sep 15th, 2011, 10:01 AM.

  • #2
    Please be polite and don't type all upper case, large letters, that will not make much friends here.

    The answer is actually quite simple in general if you use a spring application you also use spring to manage your transactions/resources and as such the spring factory bean makes that assumption and in that case you don't want quartz to manage transaction but want spring to be in control.

    Comment


    • #3
      Hi Marten,

      Thanks for your reply.

      About not typing large letters.... I'm seeing triggers stuck in the ACQUIRED state, or other weird data problems is the title. It is a quote from Quartz documentation which original has bigger title.

      Thanks again,


      nicolas.loriente

      Comment


      • #4
        Solution

        I found the following solution:
        org.quartz.jobStore.dontSetAutoCommitFalse=false
        org.quartz.scheduler.wrapJobExecutionInUserTransac tion=true

        Because LocalDataSourceJobStore extends JobStoreCMT to be used in an application-server environment that provides container-managed-transactions. No commit / rollback will be1 handled by this class. So that will be do by container (JTA transactions)

        Comment


        • #5
          Another way to resolve issue

          As it is described in Spring documentation for SchedulerFactoryBean (http://static.springsource.org/sprin...oryBean.html): whenever you use QUARTZ scheduler (for example, schedule job dynamically), wrap your method to Spring transaction using @Transactional annotation. That will resolve "stuck jobs" issue.

          Previously described by me solution works but can call another issue: transaction will live so long as job executes and that can cause issue if timeout for JTA transaction is less than job's execution time: job will be stopped from execution.

          Comment


          • #6
            hrm...

            Originally posted by Marten Deinum View Post
            Please be polite and don't type all upper case, large letters, that will not make much friends here.

            The answer is actually quite simple in general if you use a spring application you also use spring to manage your transactions/resources and as such the spring factory bean makes that assumption and in that case you don't want quartz to manage transaction but want spring to be in control.
            Passive agressive much? I didn't think this was rude at ALL Good post about the mysteries of the double negative set-auto-commit prop. The real question is... why would Quartz make this a double negative and not more straight foward? Shame on them.

            Comment

            Working...
            X