db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (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 Wed, 30 Apr 2014 21:29:15 GMT

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

Mime
View raw message