db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5564) Code does different things depending if derby.locks.deadlockTrace=true is set
Date Tue, 10 Jan 2012 10:00:38 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183171#comment-13183171
] 

Knut Anders Hatlen commented on DERBY-5564:
-------------------------------------------

The patch looks fine to me. You might want to update some more references to the old state,
though:

- LazyDefaultSchemaCreationTest: the constant LOCK_TIMEOUT_LOG is no longer used and could
be removed

- StressTestMulti: lists 40XL2 as a state to ignore in a couple of places

- the translated messages still use the old message id

Nit: The method name isLockTimeoutOrLockDeadlockStandardException() is a mouthful. Perhaps
something simpler, like isLockTimeoutOrDeadlock(), would be just as good. (And similar: isLockTimeoutStandardException()
-> isLockTimeout())
                
> Code does different things depending if derby.locks.deadlockTrace=true is set
> -----------------------------------------------------------------------------
>
>                 Key: DERBY-5564
>                 URL: https://issues.apache.org/jira/browse/DERBY-5564
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client, Network Server
>    Affects Versions: 10.8.2.2
>         Environment: Solaris 10
> Glassfish V2.1.1
>            Reporter: Brett Bergquist
>            Assignee: Mike Matrigali
>         Attachments: DERBY-5564.patch, derby-5564_2.patch
>
>
> I see a problem in the code handling lock timeout exceptions.  In the code in various
places there are calls such as:
>             // 2 kinds of errors here expected here.  Either container not 
>             // found or could not obtain lock (LOCK_TIMEOUT or DEADLOCK).
>             //
>             // It is possible by the time this post commit work gets scheduled 
>             // that the container has been dropped and that the open container 
>             // call will return null - in this case just return assuming no 
>             // work to be done.
>                                                 if (se.getMessageId().equals(SQLState.LOCK_TIMEOUT)
||
>                                                                 se.getMessageId().equals(SQLState.DEADLOCK))
> Or  
>         // First try to do the work in the nested transaction. Fail if we can't
>         // get a lock immediately.
>         if ( nestedTransaction != null )
>         {
>             try {
>                 return updateCurrentValueOnDisk( nestedTransaction, oldValue, newValue,
false );
>             }
>             catch (StandardException se)
>             {
>                 if ( !se.getMessageId().equals( SQLState.LOCK_TIMEOUT ) ) { throw se;
}
>             }
> Or
>             // exception might have occured either container got dropper or lock not
granted.
>             // It is possible by the time this post commit work gets scheduled 
>             // that the container has been dropped and that the open container 
>             // call will return null - in this case just return assuming no 
>             // work to be done.
>                                                 //If this expcetion is because lock could
not be obtained , work is requeued.
>                                                 if (se.getMessageId().equals(SQLState.LOCK_TIMEOUT)
|| 
>                                                                 se.getMessageId().equals(SQLState.DEADLOCK))
>                                                 {
>                                                                 requeue_work = true;
>                                                 }
> The problem that I see is that if the property "derby.locks.deadlockTrace=true" is set,
then instead of a SQLState.LOCK_TIMEOUT, the code will see a SQLState.LOCK_TIMEOUT_LOG.  Note
that this is not being checked for in the above tests and others as well, so now the code
behavior is going to change basd on whether the lock tracing is enabled or not.    
> I think that 99% of the code that is testing for SQLState.LOCK_TIMEOUT should also be
checking for SQLState.LOCK_TIMEOUT_LOG as well.    I only see one place in DDLConstantAction
where it is explicitly mentioned that SQLState.LOCK_TIMEOUT_LOG is not being looked at.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message