[
https://issues.apache.org/jira/browse/DERBY-6554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13986571#comment-13986571
]
Rick Hillegas commented on DERBY-6554:
--------------------------------------
Hi Mike,
Here are some responses to your previous two comments. I hope I am addressing
your questions. Ask me again if I have inadvertently missed something.
----------------------
How likely/real is it that someone will use a sequence generator in the
transaction which created it?
Very unlikely. That is why this bug was discovered in the laboratory and not
discovered in production. I think that most applications do their DDL first as
part of application-installation. However, I suppose you could imagine an
application which scales itself by cloning its schema on the fly. The cloning
transaction might have to exercise the sequence generator during
initialization. New connections would back up behind the cloning transaction,
waiting for it to commit and signal that initialization had completed.
---------------------------------
What is SequenceUpdater doing today?
There are 3 kinds of writes to SYS.SYSSEQUENCES:
A) The initial row insertion by CREATE SEQUENCE.
B) Periodic allocations of new ranges of sequence values.
C) Flushing unused sequence values.
i) This happens if the cache of sequence generators fills up and an active
sequence generator has to be evicted from the cache. That is, merely using
another, unrelated sequence generator can cause this to happen.
ii) This also happens during DDL, which causes the DataDictionary to flush all
of its caches.
iii) This also happens during orderly database shutdown.
Right now (not including the derby-6554-01-ac-useCreationTransaction.diff
patch):
A always happens in the user's execution transaction
B and C only try to write to SYS.SYSSEQUENCES in a nested sub-transaction of
the user's execution transaction. B and C never wait for a lock. Instead, if
they can't get the lock, they timeout immediately and raise a "too much
contention" exception.
---------------------------------
What if we changed this behavior so that B and C waited for the X lock and/or
escalated into the parent transaction?
This might be ok for B, although throughput might suffer.
I think this would cause system freeze-ups for C.
--------------------------------
What if the LockManager raised a SelfDeadlock exception when a nested
sub-transaction requested an X lock held by its parent transaction?
I think this eliminates the troubling complexity of
derby-6554-01-ac-useCreationTransaction.diff. SelfDeadlock would be the only
case which caused us to escalate from the nested sub-transaction into the
parent transaction. I think that this situation will only occur under the
conditions of this bug: exercising a sequence generator in the transaction
which created it. If anyone can think of another case which gives rise to this
situation, then we'll need to think some more.
I'm happy to try my hand at this, provided that the experts are willing to
coach me.
With this extra explanation, does this still seem like the best approach to you?
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
> 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)
