[
https://issues.apache.org/jira/browse/DERBY-6554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983833#comment-13983833
]
Rick Hillegas commented on DERBY-6554:
--------------------------------------
I'm going to try the following approach unless people think that this won't
work. The idea is to add a special code path for the situation when we are
trying to use the sequence generator in the transaction which created it:
1) When the CreateSequenceConstantAction creates a sequence, it will mark the
associated SequenceUpdater with its execution TransactionController's
transaction id (what comes back from getTransactionIdString()) plus an as yet
not implemented commit/rollback counter obtained from the
TransactionController. If someone can think of a better identifier for the
execution transaction, I'm happy to use that.
2) When trying to update the sequence number on disk, the SequenceUpdater will
check to see whether the current execution transaction is the one it was marked
with. If so, we will use the execution transaction rather than a nested
subtransaction to do the work.
3) When TransactionController.commit() or abort() is called, we will bump the
commit/rollback counter.
There may be an edge-case on an edge-case to consider: creating and using a
sequence inside the nested transaction context of a stored procedure.
Your feedback is welcome.
Thanks,
-Rick
> 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)
