Quartz bothered me for two years the issue of unscheduleJob and deleteJob

Ashamed to say, this problem has troubled me two years, the system should be set through the UI regular tasks, task persistence to the database regularly to ensure that the system can still resume the task after the execution time, of course, need to cancel the regular tasks, once the cancellation task, UI is locked (in fact, the background processes are locked), need 3-5 minutes to recover, under normal circumstances, the background will report database errors.

Problems, I did not repeatedly test solution, anyway, after the lock, once resumed, another operation to deal with them very quickly, the first care.

Also last year to develop new systems, require the same components, of course, also encountered the same problem, he can not solve, so he switched to delete data directly approach to resolve, Dan Shi tight schedule, Mo too concerned about. I took to upgrade the system and found that the problem remains the same, or not to open around this problem, no way, in accordance with the formal method to fix the issues now, or else I do not know how long to poison

1. Repeated the experiment many times, the new approach can not solve the problem,

2. Again switched back to the API, unscheduleJob and deleteJob treatment, invalid

3. Doubt is the quartz version of the problem, the original version is 1.6.0, download the two versions 1.6.6,1.8.3,1.8.3 version too, spring is not recognized, and switch to 1.6.6 it, the problem remains

4. No way, modify the log4j configuration file, find out the principle of quartz to resolve it, the log is as follows

Wrote,

2010-07-22 13:37:40,796 (http-8888-Processor24) [DBSemaphore.java: 106: DEBUG] Lock 'TRIGGER_ACCESS' is desired by: http-8888-Processor24
2010-07-22 13:37:40,796 (http-8888-Processor24) [DBSemaphore.java: 106: DEBUG] Lock 'TRIGGER_ACCESS' is desired by: http-8888-Processor24
2010-07-22 13:37:40,796 (http-8888-Processor24) [StdRowLockSemaphore.java: 89: DEBUG] Lock 'TRIGGER_ACCESS' is being obtained: http-8888-Processor24
2010-07-22 13:37:40,796 (http-8888-Processor24) [StdRowLockSemaphore.java: 89: DEBUG] Lock 'TRIGGER_ACCESS' is being obtained: http-8888-Processor24
2010-07-22 13:37:40,796 (http-8888-Processor24) [DBSemaphore.java: 115: DEBUG] Lock 'TRIGGER_ACCESS' given to: http-8888-Processor24
2010-07-22 13:37:40,796 (http-8888-Processor24) [DBSemaphore.java: 115: DEBUG] Lock 'TRIGGER_ACCESS' given to: http-8888-Processor24
2010-07-22 13:37:40,828 (http-8888-Processor24) [DBSemaphore.java: 142: DEBUG] Lock 'TRIGGER_ACCESS' returned by: http-8888-Processor24
2010-07-22 13:37:40,828 (http-8888-Processor24) [DBSemaphore.java: 142: DEBUG] Lock 'TRIGGER_ACCESS' returned by: http-8888-Processor24
2010-07-22 13:37:53,406 (http-8888-Processor24) [DBSemaphore.java: 106: DEBUG] Lock 'TRIGGER_ACCESS' is desired by: http-8888-Processor24
2010-07-22 13:37:53,406 (http-8888-Processor24) [DBSemaphore.java: 106: DEBUG] Lock 'TRIGGER_ACCESS' is desired by: http-8888-Processor24
2010-07-22 13:37:53,406 (http-8888-Processor24) [StdRowLockSemaphore.java: 89: DEBUG] Lock 'TRIGGER_ACCESS' is being obtained: http-8888-Processor24
2010-07-22 13:37:53,406 (http-8888-Processor24) [StdRowLockSemaphore.java: 89: DEBUG] Lock 'TRIGGER_ACCESS' is being obtained: http-8888-Processor24
2010-07-22 13:37:53,406 (http-8888-Processor24) [DBSemaphore.java: 115: DEBUG] Lock 'TRIGGER_ACCESS' given to: http-8888-Processor24
2010-07-22 13:37:53,406 (http-8888-Processor24) [DBSemaphore.java: 115: DEBUG] Lock 'TRIGGER_ACCESS' given to: http-8888-Processor24
2010-07-22 13:37:53,421 (http-8888-Processor24) [DBSemaphore.java: 142: DEBUG] Lock 'TRIGGER_ACCESS' returned by: http-8888-Processor24
2010-07-22 13:37:53,421 (http-8888-Processor24) [DBSemaphore.java: 142: DEBUG] Lock 'TRIGGER_ACCESS' returned by: http-8888-Processor24
$ $ UnschedualResult = false
2010-07-22 13:37:53,421 (http-8888-Processor24) [DBSemaphore.java: 106: DEBUG] Lock 'TRIGGER_ACCESS' is desired by: http-8888-Processor24
2010-07-22 13:37:53,421 (http-8888-Processor24) [DBSemaphore.java: 106: DEBUG] Lock 'TRIGGER_ACCESS' is desired by: http-8888-Processor24
2010-07-22 13:37:53,421 (http-8888-Processor24) [StdRowLockSemaphore.java: 89: DEBUG] Lock 'TRIGGER_ACCESS' is being obtained: http-8888-Processor24
2010-07-22 13:37:53,421 (http-8888-Processor24) [StdRowLockSemaphore.java: 89: DEBUG] Lock 'TRIGGER_ACCESS' is being obtained: http-8888-Processor24
2010-07-22 13:37:53,421 (http-8888-Processor24) [DBSemaphore.java: 115: DEBUG] Lock 'TRIGGER_ACCESS' given to: http-8888-Processor24
2010-07-22 13:37:53,421 (http-8888-Processor24) [DBSemaphore.java: 115: DEBUG] Lock 'TRIGGER_ACCESS' given to: http-8888-Processor24
2010-07-22 13:38:07,796 (http-8888-Processor24) [ExceptionHelper.java: 97: DEBUG] Detected JDK support for nested exceptions.
2010-07-22 13:38:07,796 (http-8888-Processor24) [ExceptionHelper.java: 97: DEBUG] Detected JDK support for nested exceptions.
2010-07-22 13:38:07,796 (http-8888-Processor24) [DBSemaphore.java: 142: DEBUG] Lock 'TRIGGER_ACCESS' returned by: http-8888-Processor24
2010-07-22 13:38:07,796 (http-8888-Processor24) [DBSemaphore.java: 142: DEBUG] Lock 'TRIGGER_ACCESS' returned by: http-8888-Processor24
org.quartz.JobPersistenceException: Couldn't remove job: ORA-02292: integrity constraint violation conditions (SYS_C0016583) - have found the child records
[See nested exception: java.sql.SQLException: ORA-02292: integrity constraint violation conditions (SYS_C0016583) - have found the child records
]
at org.quartz.impl.jdbcjobstore.JobStoreSupport.removeJob (JobStoreSupport.java: 1313)
at org.quartz.impl.jdbcjobstore.JobStoreSupport $ 6.execute (JobStoreSupport.java: 1293)
at org.quartz.impl.jdbcjobstore.JobStoreCMT.executeInLock (JobStoreCMT.java: 244)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.removeJob (JobStoreSupport.java: 1289)
at org.quartz.core.QuartzScheduler.deleteJob (QuartzScheduler.java: 835)
at org.quartz.impl.StdScheduler.deleteJob (StdScheduler.java: 300)

Remember the source code there StdRowLockSemaphore, and strange, the code inside the system, check the quartz of the code, but also have the class to compare it

package org.quartz.impl.jdbcjobstore;

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

/**
 * Internal database based lock handler for providing thread/resource locking
 * in order to protect resources from being altered by multiple threads at the
 * same time.
 *
 * @author jhouse
 */
public class StdRowLockSemaphore extends DBSemaphore {

    /*
     * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     *
     * Constants.
     *
     * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     */

    public static final String SELECT_FOR_LOCK = "SELECT * FROM "
            + TABLE_PREFIX_SUBST + TABLE_LOCKS + " WHERE " + COL_LOCK_NAME
            + " = ? FOR UPDATE";

    /*
     * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     *
     * Constructors.
     *
     * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     */

    /**
     * This constructor is for using the <code>StdRowLockSemaphore</code> as
     * a bean.
     */
    public StdRowLockSemaphore() {
        super(DEFAULT_TABLE_PREFIX, null, SELECT_FOR_LOCK);
    }

    public StdRowLockSemaphore(String tablePrefix, String selectWithLockSQL) {
        super(tablePrefix, selectWithLockSQL, SELECT_FOR_LOCK);
    }

    /*
     * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     *
     * Interface.
     *
     * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     */

    /**
     * Execute the SQL select for update that will lock the proper database row.
     */
    protected void executeSQL(Connection conn, String lockName, String expandedSQL) throws LockException {
        PreparedStatement ps = null;
        ResultSet rs = null;
        try {
                conn.setAutoCommit(false);
            ps = conn.prepareStatement(expandedSQL);
            ps.setString(1, lockName);

            if (getLog().isDebugEnabled()) {
                getLog().debug(
                    "Lock '" + lockName + "' is being obtained: " +
                    Thread.currentThread().getName());
            }
            rs = ps.executeQuery();
            if (!rs.next()) {
                throw new SQLException(Util.rtp(
                    "No row exists in table " + TABLE_PREFIX_SUBST +
                    TABLE_LOCKS + " for lock named: " + lockName, getTablePrefix()));
            }
            conn.commit();
        } catch (SQLException sqle) {
            //Exception src =
            // (Exception)getThreadLocksObtainer().get(lockName);
            //if(src != null)
            //  src.printStackTrace();
            //else
            //  System.err.println("--- ***************** NO OBTAINER!");

            if (getLog().isDebugEnabled()) {
                getLog().debug(
                    "Lock '" + lockName + "' was not obtained by: " +
                    Thread.currentThread().getName());
            }

            throw new LockException("Failure obtaining db row lock: "
                    + sqle.getMessage(), sqle);
        } finally {
            if (rs != null) {
                try {
                    rs.close();
                } catch (Exception ignore) {
                }
            }
            if (ps != null) {
                try {
                    ps.close();
                } catch (Exception ignore) {
                }
            }
        }
    }

    protected String getSelectWithLockSQL() {
        return getSQL();
    }

    public void setSelectWithLockSQL(String selectWithLockSQL) {
        setSQL(selectWithLockSQL);
    }
}

Found in our code which joined the two lines

conn.setAutoCommit(false);

conn.commit();

This code is the system left by the creator, then what are the considerations and not the test (code which does not comment). He certainly is inappropriate to do so.

The other problem, such a question stretches for two years to get it. . .

分类:Java 时间:2010-07-22 人气:241
分享到:
blog comments powered by Disqus

相关文章

iOS 开发

Android 开发

Python 开发

JAVA 开发

开发语言

PHP 开发

Ruby 开发

搜索

前端开发

数据库

开发工具

开放平台

Javascript 开发

.NET 开发

云计算

服务器

Copyright (C) codeweblog.com, All Rights Reserved.

CodeWeblog.com 版权所有 黔ICP备15002463号-1

processed in 0.246 (s). 12 q(s)