db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6554) Too much contention followed by assert failure when accessing sequence in transaction that created it
Date Thu, 01 May 2014 13:36:23 GMT

    [ 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)

Mime
View raw message