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 16:46:18 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13985721#comment-13985721
] 

Mike Matrigali commented on DERBY-6554:
---------------------------------------

> Why isn't the sub-transaction exclusive lock compatible with that of the parent transaction?
I.e. why can't it be granted?
The Derby recovery algorithms do not currently support compatible locking of parent transaction
and child read/write transactions.  
I believe there are a number of problems and those problems are avoided by making sure the
read/write sub transaction does not
change the same row that may have been changed by the parent transaction.  This was acceptable
when the first specific use of
the read/write transaction was created, but we have added more use cases since then.

Here is an example off the top of my head that would cause problems in the system if a read/write
sub transaction locking was compatible
with parent.  The issue is that the subtransaction can commit separate from the parent and
subsequently the parent xact may abort.

1) parent transaction gets X lock on row A and changes it.
2) (if it were allowed) read/write substransaction gets lock on row A and changes it in an
arbitrary different way.
3) subtransaction commits changes and releases locks
4) parent transaction aborts, and expects changes to row A to be backed out.  I believe this
will crash the system currently if the
    above scenario was played through as it would try to apply undo log records in reverse,
but would only look at log records associated
    with the parent transaction but will see a page version from the other transaction and
not know what to do.

note that read only substransactions do have compatible locking with parent as they present
no recovery issues.  This is what the compiler
uses to get consistent plans but not conflict with user locking.


> 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
>
>
> {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