db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (DERBY-6554) Too much contention followed by assert failure when accessing sequence in transaction that created it
Date Mon, 28 Apr 2014 19:20:15 GMT

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

Dag H. Wanvik edited comment on DERBY-6554 at 4/28/14 7:18 PM:
---------------------------------------------------------------

I think we have seen that before, yes. I seem to remember we have code that, when failing
to lock a resource in the sub-transaction, falls back to trying to use the parent transaction
instead, in case it is a self-lock scenario (like the one you are seeing). But should one
wait for lock time-out in this case before doing the fall-back? Probably not..
I think Knut has done some work with this mechanism..
See also DERBY-3693, and the method RAMTRansaction#setNoLockWait and its usage.


was (Author: dagw):
I think we have seen that before, yes. I seem to remember we have code that, when failing
to lock a resource in the sub-transaction, falls back to trying to use the parent transaction
instead, in case it is a self-lock scenario (like the one you are seeing). But should one
wait for lock time-out in this case before doing the fall-back? Probably not..
I think Knut has done some work with this mechanism..


> 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
>
> {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)

Mime
View raw message