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