[
https://issues.apache.org/jira/browse/DERBY-6554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13986791#comment-13986791
]
Mike Matrigali commented on DERBY-6554:
---------------------------------------
I still lean toward some approach that defaults the work to a subtransaction,
and then escalates
the work to the parent transaction based on some condition.
Discounting the work involved I do believe the lock manager recognizing the
self deadlock is the
best solution, if it could be implemented with negatively impacting the
throughput of all locks through
the system. A solution that updated the current deadlock algorithm to be
executed after system set
deadlock wait time would be fine. I am not sure if a solution that checked on
every wait would be
good -but might be if you could do a simple check that only looked at the data
of the lock in question
after it was noticed it had to wait. I am not sure if the current lock manager
data has the necessary child/parent relationships
necessary. I have not looked at the lock manager since it was partially
rewritten multiple years ago
so not sure how much I could help with this.
I think the following will achieve the same result but no lock manager change,
I do understand
how to do the locking part and would be happy to help if you would prefer this
approach to the
lock manager change. There is a cost of an extra lock request per sequencer
update for this
approach.
1) change code to wait for the lock and on timeout retry in parent transaction,
and if that fails I guess
continue to throw too much contention. Is there an argument to just not
allow timeout in this case?
2) implement the following that would require no lock manager code change:
add new lock that will cause sub transaction to wait on other
subtransactions but not on
parent transactions, and then change subtracation to wait first on the new
lock, and then to
continue to nowait on the existing sequencer lock, with escalation code
from 1 if it can't get
lock.
If this does not work for C) Flushing unused sequence values. - maybe there is
some special case we
can use for that?
> 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)
