You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Brett Bergquist (Created) (JIRA)" <ji...@apache.org> on 2012/01/03 15:40:39 UTC
[jira] [Created] (DERBY-5564) Code does different things depending
if derby.locks.deadlockTrace=true is set
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
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
[jira] [Commented] (DERBY-5564) Code does different things
depending if derby.locks.deadlockTrace=true is set
Posted by "Mike Matrigali (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183580#comment-13183580 ]
Mike Matrigali commented on DERBY-5564:
---------------------------------------
I have not previously ever made a change to translated error message files. Is there any special considerations with editors an such to not corrupting them? I assume I just need to change all the 40XL2 references to 40XL1.T.1
> 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
[jira] [Commented] (DERBY-5564) Code does different things
depending if derby.locks.deadlockTrace=true is set
Posted by "Knut Anders Hatlen (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (DERBY-5564) Code does different things depending
if derby.locks.deadlockTrace=true is set
Posted by "Mike Matrigali (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-5564:
----------------------------------
Fix Version/s: 10.8.2.3
backported change to 10.8.
> 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.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.2.1, 10.7.1.1, 10.8.2.2
> Environment: Solaris 10
> Glassfish V2.1.1
> Reporter: Brett Bergquist
> Assignee: Mike Matrigali
> Fix For: 10.8.2.3, 10.9.0.0
>
> Attachments: DERBY-5564.patch, derby-5564_2.patch, derby-5564_3.patch, releaseNote.html, releaseNote.html
>
>
> 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
[jira] [Updated] (DERBY-5564) Code does different things depending
if derby.locks.deadlockTrace=true is set
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-5564:
----------------------------------
Attachment: releaseNote.html
Updating release note summary per Rick's recommendation
> 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.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.2.1, 10.7.1.1, 10.8.2.2
> Environment: Solaris 10
> Glassfish V2.1.1
> Reporter: Brett Bergquist
> Assignee: Mike Matrigali
> Fix For: 10.5.3.2, 10.6.2.3, 10.7.1.4, 10.8.2.3, 10.9.1.0
>
> Attachments: derby-5564_2.patch, derby-5564_3.patch, DERBY-5564.patch, releaseNote.html, releaseNote.html, releaseNote.html
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5564) Code does different things
depending if derby.locks.deadlockTrace=true is set
Posted by "Mike Matrigali (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184144#comment-13184144 ]
Mike Matrigali commented on DERBY-5564:
---------------------------------------
All tests passed, committed to trunk:
s1_ibm16:18>svn commit
Sending java\engine\org\apache\derby\iapi\error\StandardException.java
Sending java\engine\org\apache\derby\iapi\sql\dictionary\SPSDescriptor.java
Sending java\engine\org\apache\derby\impl\services\daemon\IndexStatisticsDaemonImpl.java
Sending java\engine\org\apache\derby\impl\sql\catalog\SequenceUpdater.java
Sending java\engine\org\apache\derby\impl\sql\execute\DDLConstantAction.java
Sending java\engine\org\apache\derby\impl\sql\execute\LockTableConstantAction.java
Sending java\engine\org\apache\derby\impl\store\access\btree\BTreePostCommit.java
Sending java\engine\org\apache\derby\impl\store\access\heap\HeapPostCommit.java
Sending java\engine\org\apache\derby\impl\store\raw\data\ReclaimSpaceHelper.java
Sending java\engine\org\apache\derby\impl\store\raw\xact\Xact.java
Sending java\engine\org\apache\derby\jdbc\XATransactionState.java
Sending java\engine\org\apache\derby\loc\messages.xml
Sending java\engine\org\apache\derby\loc\messages_cs.properties
Sending java\engine\org\apache\derby\loc\messages_de_DE.properties
Sending java\engine\org\apache\derby\loc\messages_es.properties
Sending java\engine\org\apache\derby\loc\messages_fr.properties
Sending java\engine\org\apache\derby\loc\messages_hu.properties
Sending java\engine\org\apache\derby\loc\messages_it.properties
Sending java\engine\org\apache\derby\loc\messages_ja_JP.properties
Sending java\engine\org\apache\derby\loc\messages_ko_KR.properties
Sending java\engine\org\apache\derby\loc\messages_pl.properties
Sending java\engine\org\apache\derby\loc\messages_pt_BR.properties
Sending java\engine\org\apache\derby\loc\messages_ru.properties
Sending java\engine\org\apache\derby\loc\messages_zh_CN.properties
Sending java\engine\org\apache\derby\loc\messages_zh_TW.properties
Sending java\shared\org\apache\derby\shared\common\reference\SQLState.java
Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\ErrorMessageTest.java
Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\LazyDefaultSchemaCreationTest.java
Transmitting file data ............................
Committed revision 1230100.
> 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, derby-5564_3.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
[jira] [Commented] (DERBY-5564) Code does different things
depending if derby.locks.deadlockTrace=true is set
Posted by "Knut Anders Hatlen (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179916#comment-13179916 ]
Knut Anders Hatlen commented on DERBY-5564:
-------------------------------------------
Applications typically check the SQLState, not the message id. To get the message id, they'd first need to unwrap the SQLException to get the underlying StandardException, and StandardException is not part of the public API. So I don't think it would affect existing applications. Except, as Brett mentioned, if the applications check for SQLState 40XL2 without also checking for 40XL1. We should probably mention that in the release notes.
> 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
>
>
> 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
[jira] [Commented] (DERBY-5564) Code does different things
depending if derby.locks.deadlockTrace=true is set
Posted by "Knut Anders Hatlen (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179844#comment-13179844 ]
Knut Anders Hatlen commented on DERBY-5564:
-------------------------------------------
Perhaps it could be as simple as changing LOCK_TIMEOUT_LOG to 40XL1.S.1 (and changing the corresponding entry in messages.xml), and checking getSQLState() instead of getMessageId() (since the former strips off the .S.1 suffix).
> 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
>
>
> 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
[jira] [Updated] (DERBY-5564) Code does different things depending
if derby.locks.deadlockTrace=true is set
Posted by "Mike Matrigali (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-5564:
----------------------------------
Fix Version/s: 10.9.0.0
> 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
> Fix For: 10.9.0.0
>
> Attachments: DERBY-5564.patch, derby-5564_2.patch, derby-5564_3.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
[jira] [Updated] (DERBY-5564) Code does different things depending
if derby.locks.deadlockTrace=true is set
Posted by "Brett Bergquist (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brett Bergquist updated DERBY-5564:
-----------------------------------
Attachment: DERBY-5564.patch
The attached patch adds a new "isLockStandardException" static method to StandardException that checks for either LOCK_TIMEOUT or LOCK_TIMEOUT_LOG and returns true if the exception is either one.
The rest of the patch fixes the places in the code where only LOCK_TIMEOUT was being checked for to use this new method except for the change in EmbedXAResource.java which only has an SQLException to work with, not a StandardException.
> 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
> Attachments: DERBY-5564.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
[jira] [Commented] (DERBY-5564) Code does different things
depending if derby.locks.deadlockTrace=true is set
Posted by "Mike Matrigali (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179861#comment-13179861 ]
Mike Matrigali commented on DERBY-5564:
---------------------------------------
Would Knut's proposed change work with existing user applications? It seems like a better solution if it works with existing applications. I believe the SQL state is part of the standard, so seems like it should work.
> 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
>
>
> 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
[jira] [Commented] (DERBY-5564) Code does different things
depending if derby.locks.deadlockTrace=true is set
Posted by "Dag H. Wanvik (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184809#comment-13184809 ]
Dag H. Wanvik commented on DERBY-5564:
--------------------------------------
Thanks for the release notes. Looks good. Nit: the last sentence in that rationale looked weird, maybe it had an extraneous period inside it?
> 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.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.2.1, 10.7.1.1, 10.8.2.2
> Environment: Solaris 10
> Glassfish V2.1.1
> Reporter: Brett Bergquist
> Assignee: Mike Matrigali
> Fix For: 10.9.0.0
>
> Attachments: DERBY-5564.patch, derby-5564_2.patch, derby-5564_3.patch, releaseNote.html
>
>
> 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
[jira] [Updated] (DERBY-5564) Code does different things depending
if derby.locks.deadlockTrace=true is set
Posted by "Mike Matrigali (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-5564:
----------------------------------
Attachment: derby-5564_3.patch
I believe this patch addresses Knut's review comments. Still have to run nightly tests, so not ready for review. My last run saw some issues in upgrade, which may be cascade from errors in NativeAuth test failures I am seeing
on my laptop. So working through those first.
> 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, derby-5564_3.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
[jira] [Updated] (DERBY-5564) Code does different things depending
if derby.locks.deadlockTrace=true is set
Posted by "Mike Matrigali (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-5564:
----------------------------------
Attachment: releaseNote.html
removed extraneous text noted by review comments.
> 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.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.2.1, 10.7.1.1, 10.8.2.2
> Environment: Solaris 10
> Glassfish V2.1.1
> Reporter: Brett Bergquist
> Assignee: Mike Matrigali
> Fix For: 10.9.0.0
>
> Attachments: DERBY-5564.patch, derby-5564_2.patch, derby-5564_3.patch, releaseNote.html, releaseNote.html
>
>
> 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
[jira] [Commented] (DERBY-5564) Code does different things
depending if derby.locks.deadlockTrace=true is set
Posted by "Knut Anders Hatlen (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183640#comment-13183640 ]
Knut Anders Hatlen commented on DERBY-5564:
-------------------------------------------
The message files only contain plain ascii characters, so any text editor that handles ascii should be fine. Or use perl:
perl -pi -e s/40XL2/40XL1.T.1/g messages*.properties
> 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
[jira] [Updated] (DERBY-5564) Code does different things depending
if derby.locks.deadlockTrace=true is set
Posted by "Mike Matrigali (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-5564:
----------------------------------
Affects Version/s: 10.1.3.1
10.2.2.0
10.3.3.0
10.4.2.0
10.5.3.0
10.6.2.1
10.7.1.1
issue has existed at least as far back as 10.1
> 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.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.2.1, 10.7.1.1, 10.8.2.2
> Environment: Solaris 10
> Glassfish V2.1.1
> Reporter: Brett Bergquist
> Assignee: Mike Matrigali
> Fix For: 10.9.0.0
>
> Attachments: DERBY-5564.patch, derby-5564_2.patch, derby-5564_3.patch, releaseNote.html
>
>
> 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
[jira] [Commented] (DERBY-5564) Code does different things
depending if derby.locks.deadlockTrace=true is set
Posted by "Knut Anders Hatlen (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179918#comment-13179918 ]
Knut Anders Hatlen commented on DERBY-5564:
-------------------------------------------
By the way, I think the severity suffix should be .T, not .S as suggested above, since lock timeouts are transaction severity errors.
> 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
>
>
> 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
[jira] [Commented] (DERBY-5564) Code does different things
depending if derby.locks.deadlockTrace=true is set
Posted by "Bryan Pendleton (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179231#comment-13179231 ]
Bryan Pendleton commented on DERBY-5564:
----------------------------------------
+1 to both of the above comments:
- I like the idea of a "isLockException()" method on StandardException so that
code doesn't have to do getMessageId().equals()
- I agree that it seems wrong that setting deadlockTrace=true causes a
different exception to be thrown
> 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
> Attachments: DERBY-5564.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
[jira] [Assigned] (DERBY-5564) Code does different things depending
if derby.locks.deadlockTrace=true is set
Posted by "Mike Matrigali (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali reassigned DERBY-5564:
-------------------------------------
Assignee: Mike Matrigali
> 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
>
>
> 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
[jira] [Commented] (DERBY-5564) Code does different things
depending if derby.locks.deadlockTrace=true is set
Posted by "Mike Matrigali (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179939#comment-13179939 ]
Mike Matrigali commented on DERBY-5564:
---------------------------------------
In DDLConstantAction.java is the following comment. After my proposed change there will be no difference between the 2 lock timeout cases, which I think is ok, but wanted to point it out:
if (se.getMessageId().equals(SQLState.LOCK_TIMEOUT)) {
// We don't test for SQLState.DEADLOCK or
// .LOCK_TIMEOUT_LOG here because a) if it is a
// deadlock, it may be better to expose it, and b)
// LOCK_TIMEOUT_LOG happens when the app has set
// derby.locks.deadlockTrace=true, in which case we
// don't want to mask the timeout. So in both the
// latter cases we just throw.
if (useTc == nestedTc) {
// clean up after use of nested transaction,
// then try again in outer transaction
useTc = tc;
nestedTc.destroy();
continue;
}
> 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
>
>
> 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
[jira] [Commented] (DERBY-5564) Code does different things
depending if derby.locks.deadlockTrace=true is set
Posted by "Kathey Marsden (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178865#comment-13178865 ]
Kathey Marsden commented on DERBY-5564:
---------------------------------------
It seems in general problematic that we throw exceptions with different SQLStates with derby.locks.deadlockTrace=true.
String LOCK_TIMEOUT = "40XL1";
String LOCK_TIMEOUT_LOG = "40XL2";
Lock timeout is something that applications might generally check for and if they start getting 40XL2 instead 40XL2, just enabling the diagnostic property could change behavior which would make the diagnostics more frustrating than helpful.
> 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
> Attachments: DERBY-5564.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
[jira] [Updated] (DERBY-5564) Code does different things depending
if derby.locks.deadlockTrace=true is set
Posted by "Mike Matrigali (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-5564:
----------------------------------
Attachment: releaseNote.html
adding release note for the issue.
> 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
> Fix For: 10.9.0.0
>
> Attachments: DERBY-5564.patch, derby-5564_2.patch, derby-5564_3.patch, releaseNote.html
>
>
> 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
[jira] [Commented] (DERBY-5564) Code does different things
depending if derby.locks.deadlockTrace=true is set
Posted by "Bryan Pendleton (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13180447#comment-13180447 ]
Bryan Pendleton commented on DERBY-5564:
----------------------------------------
+1 to using SQLState rather than MessageId.
> 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
>
>
> 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
[jira] [Commented] (DERBY-5564) Code does different things
depending if derby.locks.deadlockTrace=true is set
Posted by "Brett Bergquist (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179803#comment-13179803 ]
Brett Bergquist commented on DERBY-5564:
----------------------------------------
This might break application clients that are looking for 40XL2 only but I think that would be remote. Probably if a client is setup to check for a 40XL2 it more than likely is also checking for a 40XL1 so this change would have no real affect other than leaving code in a client that will never be hit.
I am not apposed to the change.
> 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
>
>
> 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
[jira] [Commented] (DERBY-5564) Code does different things
depending if derby.locks.deadlockTrace=true is set
Posted by "Mike Matrigali (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179785#comment-13179785 ]
Mike Matrigali commented on DERBY-5564:
---------------------------------------
I will look at getting this fix in, but plan to change the patch such that only 40XL1 is returned in either case, and somehow the text of the error is changed based on the diagnostic level. This will likely change the error message and maybe number of arguments to the error message - I have not looked closely yet. Let me know if anyone is opposed to this approach.
> 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
>
>
> 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
[jira] [Commented] (DERBY-5564) Code does different things
depending if derby.locks.deadlockTrace=true is set
Posted by "Knut Anders Hatlen (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183984#comment-13183984 ]
Knut Anders Hatlen commented on DERBY-5564:
-------------------------------------------
Thanks, Mike. The #3 patch addresses all my comments. +1 to commit if the tests pass.
> 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, derby-5564_3.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
[jira] [Updated] (DERBY-5564) Code does different things depending
if derby.locks.deadlockTrace=true is set
Posted by "Mike Matrigali (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-5564:
----------------------------------
Attachment: derby-5564_2.patch
I have updated the previous patch to include test changes, and have changed LOCK_TIMEOUT_LOG to return the same SQL state as LOCK_TIMEOUT as suggested. I have left the behavior of DDLConstantAction with reguard to LOCK_TIMEOUT_LOG the same, so it will still immediately throw an exception in this case rather than retry.
A patch very similar to this has passed all tests except for failures in NativeAuthProcs which consistently fail on my machine against a clean codeline on the trunk, i will run a full set of tests on this patch tonight.
> 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
[jira] [Resolved] (DERBY-5564) Code does different things depending
if derby.locks.deadlockTrace=true is set
Posted by "Mike Matrigali (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali resolved DERBY-5564.
-----------------------------------
Resolution: Fixed
Fix Version/s: 10.7.1.4
10.6.2.3
10.5.3.2
fixed issue and backported from trunk to 10.8, 10.7, 10.6 and 10.5 branches.
> 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.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.3.0, 10.6.2.1, 10.7.1.1, 10.8.2.2
> Environment: Solaris 10
> Glassfish V2.1.1
> Reporter: Brett Bergquist
> Assignee: Mike Matrigali
> Fix For: 10.5.3.2, 10.6.2.3, 10.7.1.4, 10.8.2.3, 10.9.0.0
>
> Attachments: DERBY-5564.patch, derby-5564_2.patch, derby-5564_3.patch, releaseNote.html, releaseNote.html
>
>
> 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
[jira] [Commented] (DERBY-5564) Code does different things
depending if derby.locks.deadlockTrace=true is set
Posted by "Mike Matrigali (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184528#comment-13184528 ]
Mike Matrigali commented on DERBY-5564:
---------------------------------------
I am planning on backporting this fix, let me know if you don't think it should be.
> 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
> Fix For: 10.9.0.0
>
> Attachments: DERBY-5564.patch, derby-5564_2.patch, derby-5564_3.patch, releaseNote.html
>
>
> 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
[jira] [Updated] (DERBY-5564) Code does different things depending
if derby.locks.deadlockTrace=true is set
Posted by "Mike Matrigali (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-5564:
----------------------------------
Issue & fix info: High Value Fix,Patch Available,Release Note Needed
marking that a release note should be included noting that a different error code will be returned in the case of a timeout when extra diagnostics are enabled. proposal is to return different text but to return the same LOCK_TIMEOUT sql state in both cases.
> 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
>
>
> 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