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

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

Could we perhaps try to lock it in the parent transaction no-wait before we 
give up with too much contention? Then we would use the parent transaction if 
the parent transaction already holds locks that would block others from using 
the sequence anyway, but not wait if there's some other transaction that's 
locking the sequence.

Such a solution would open a small window for unwanted lock escalations, 
though. If another transaction holds a lock that prevents the subtransaction 
from doing its work, and releases the lock before it is retried in the main 
transaction, it would end up being locked in the main transaction even though 
it wasn't the main transaction that held the lock in the first place.

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

Reply via email to