[jira] [Commented] (DERBY-6554) Too much contention followed by assert failure when accessing sequence in transaction that created it

[Knut Anders Hatlen (JIRA)]

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

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

Sorry for the late response. I missed most of this discussion while the Apache 
mail server was down.

Rick said:

{quote}
I don't think so. It appears to me that ConcurrentLockSet.lockObject() returns 
null if you can't get a lock immediately and (AbstractPool.noLockWait(timeout, 
compatibilitySpace) == true). But I don't understand what condition sets up the 
special "else" case in AbstractPool.noLockWait():
{code}
    static boolean noLockWait(int timeout, CompatibilitySpace compat) {
        if (timeout == C_LockFactory.NO_WAIT) {
            return true;
        } else {
            LockOwner owner = compat.getOwner();
            return owner != null && owner.noWait();
        }
    }
{code}
{quote}

The else branch is currently used when storing SPSs and by the index statistics 
daemon. Look for callers of TransactionController.setNoLockWait(). In those 
cases, waiting is disabled for the entire transaction, even if a no-wait flag 
isn't given as argument to the scan. That means the lock manager will see a 
request for a timed wait, but it will handle it as a no-wait request because of 
the flag on the transaction.

> Too much contention followed by assert failure when accessing sequence in 
> transaction that created it
> -----------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-6554
>                 URL: https://issues.apache.org/jira/browse/DERBY-6554
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.9.1.0, 10.11.0.0, 10.10.2.0
>            Reporter: Knut Anders Hatlen
>         Attachments: D6554.java, D6554_2.java, 
> derby-6554-01-aa-useCreationTransaction.diff, 
> derby-6554-01-ab-useCreationTransaction.diff, 
> derby-6554-01-ac-useCreationTransaction.diff, derby-6554-01-ad-bugfixes.diff, 
> derby-6554-02-aa-selfDeadlock.diff, derby-6554-02-ab-selfDeadlock.diff, 
> derby-6554-02-ac-selfDeadlock.diff, 
> derby-6554-02-ae-selfDeadlock_sps_compress.diff, 
> derby-6554-02-af-askToRaiseSelfDeadlock.diff, 
> derby-6554-02-ag-raiseSelfDeadlockAlways.diff
>
>
> {noformat}
> ij version 10.11
> ij> connect 'jdbc:derby:memory:db;create=true' as c1;
> ij> autocommit off;
> ij> create sequence seq;
> 0 rows inserted/updated/deleted
> ij> values next value for seq;
> 1          
> -----------
> ERROR X0Y84: Too much contention on sequence SEQ. This is probably caused by 
> an uncommitted scan of the SYS.SYSSEQUENCES catalog. Do not query this 
> catalog directly. Instead, use the SYSCS_UTIL.SYSCS_PEEK_AT_SEQUENCE function 
> to view the current value of a query generator.
> ij> rollback;
> ERROR 08003: No current connection.
> ij> connect 'jdbc:derby:memory:db' as c2;
> ij(C2)> autocommit off;
> ij(C2)> create sequence seq;
> 0 rows inserted/updated/deleted
> ij(C2)> values next value for seq;
> 1          
> -----------
> ERROR 38000: The exception 
> 'org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED Identity 
> being changed on a live cacheable. Old uuidString = 
> 0ddd00a9-0145-98ba-79df-000007d88b08' was thrown while evaluating an 
> expression.
> ERROR XJ001: Java exception: 'ASSERT FAILED Identity being changed on a live 
> cacheable. Old uuidString = 0ddd00a9-0145-98ba-79df-000007d88b08: 
> org.apache.derby.shared.common.sanity.AssertFailure'.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)