db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3980) Conflicting select then update with REPEATABLE_READ gives lock timeout instead of deadlock
Date Thu, 11 Dec 2008 19:18:44 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Mike Matrigali updated DERBY-3980:

how about this as start for the javadoc:
     * Do a deadlock search.
     * <p>
     * Walk through the graph of all locks and search for cycles among
     * the waiting lock requests which would indicate a deadlock.  A simple
     * deadlock cycle is where the granted locks of waiting compatibility
     * space A is blocking compatibility space B and space B holds locks causing
     * space A to wait.
     * <p>
     * Would be nice to get a better high level description of deadlock
     * search.
     * <p>
     * @return The identifier to be used to open the conglomerate later.
     * @param factory       The locking system factory
     * @param set           The complete lock table. A lock table is a hash
     *                      table keyed by a Lockable and with a LockControl as
     *                      the data element.
     * @param control       A LockControl contains a reference to the item being
     *                      locked and doubly linked lists for the granted locks
     *                      and the waiting locks.  The passed in value is the
     *                      lock that the caller was waiting on when woken up
     *                      to do the deadlock check.
     * @param startingLock  represents the specific waiting lock request that
     *                      the caller has been waiting on, before just being
     *                      woken up to do this search.
     * @deadlockWake        Either Constants.WAITING_LOCK_IN_WAIT, or
     *                      Constants.WAITING_LOCK_DEADLOCK.  I am not sure
     *                      about this one.
     * @exception  StandardException  Standard exception policy.

> Conflicting select then update with REPEATABLE_READ gives lock timeout instead of deadlock
> ------------------------------------------------------------------------------------------
>                 Key: DERBY-3980
>                 URL: https://issues.apache.org/jira/browse/DERBY-3980
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions:,,,,
>            Reporter: Kathey Marsden
>         Attachments: derby.log, derby.log.10_1, javacore.20081209.092827.9800.txt, TryTimeout.java,
TryTimeout2.java, TryTimeout2.out.10_1.deadlock, TryTimeout2.out.10_1.locktimeout
> The attached program TryTimeout.java should detect a deadlock but instead throws a lock
timeout exception.  The program has two threads that attempt:
> 	    threadConnection.setAutoCommit(false);
> 	    /* set isolation level to repeatable read */
> 	    threadConnection.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ);
> 	    ResultSet rs = stmt.executeQuery("select * from t where i = 456");
> 	    while (rs.next());
> 	    stmt.executeUpdate("update t set i = 456 where i = 456");
> 	    threadConnection.commit();
> This gives SQLState 40001 (deadlock) with DB2 but a lock timeout with Derby.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message