[
https://issues.apache.org/jira/browse/DERBY-6554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13986113#comment-13986113
]
Mike Matrigali commented on DERBY-6554:
---------------------------------------
i have not followed the most recent discussion on this, just happened to notice
the lock question. I'll think
more but here are initial thoughts based on your description in the latest
posting.
I think we had long discussions about this when you were first doing sequences
and that is what led to
the too much contention error in the sequence implementation. The proposed
solution seems overly complex to me. A lot
of mechanism to solve what should just be a locking issue with ddl in
transaction. I would lean toward what
knut suggests and just catch the error and retry in main transaction, to handle
the creating transaction case.
And maybe tune how long you wait for lock in sub transaction to get fewer false
escalations.
I think the right next project to fix the issue with incorrectly escalating to
parent is to fix the lock manager to throw deadlock
rather than lock wait when it can't get a lock because parent transaction holds
it. Not sure how hard that
project would be, but if necessary we could even special case the lock and lock
path to make it easier if no one
was up to a general change to the lock manager.
For sequences do you have some feel for the need to create and use sequences in
the same transaction. For
identity I have always been comfortable telling people to create the table and
then use it in a different transaction
if they see poor performance/contention with in transaction work. Basically is
it reasonable to require a commit
after create sequence to get best performance.
> 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
>
>
> {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)
