[
https://issues.apache.org/jira/browse/DERBY-6554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13991646#comment-13991646
]
Knut Anders Hatlen commented on DERBY-6554:
-------------------------------------------
{quote}
I can get the test case to pass by adding another restriction: Raise
SelfDeadlock only if the lock timeout is 0, that is, if we are supposed to
abort the transaction when we can't immediately get the lock. This will result
in a behavior change for the SYSCS_INPLACE_COMPRESS_TABLE case. We will raise a
SelfDeadlock exception rather than a lock timeout exception. Is this behavior
change ok?
{quote}
I'm not sure I fully understand this question. First it sounded as if adding
the extra restriction would prevent SYSCS_INPLACE_COMPRESS_TABLE from raising
SelfDeadlock. But the question seems to imply that adding the extra restriction
will make it start raising SelfDeadlock rather than lock timeout in some cases.
Exactly what does adding the extra restriction fix, and what behaviour change
does it introduce?
I think it is ok that SYSCS_INPLACE_COMPRESS_TABLE raises a lock timeout in
this case (which it currently does?), since the reference manual says "Tip: We
recommend that you issue the SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE system
procedure in auto-commit mode." Presumably that tip was added because of this
issue.
> 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
>
>
> {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)
