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

Rick Hillegas commented on DERBY-6554:
--------------------------------------

Hi Mike,

"I think this would cause system freeze-ups for C." This is what would happen 
when the cache is cleared, or a cache entry is evicted, or the system shuts 
down in an orderly way: An attempt is made to stuff the SYSSEQUENCES row with 
the next sequence number which would be doled out. Suppose that one user 
scanned SYSSEQUENCES or the lock escalated into his execution transaction. Then 
someone else tries to use another sequence which evicts the first sequence from 
the cache. Or someone else tries to do some cache-flushing DDL. Or someone else 
tries to bring down the database. That subsequent operation will block, perhaps 
twice, for the lock timeout period and will get an error message referring to 
the first sequence. Potentially lots of threads will back up behind these 
operations.

> 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, 
> derby-6554-01-aa-useCreationTransaction.diff, 
> derby-6554-01-ab-useCreationTransaction.diff, 
> derby-6554-01-ac-useCreationTransaction.diff, derby-6554-01-ad-bugfixes.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)

Reply via email to