[
https://issues.apache.org/jira/browse/DERBY-6554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13993604#comment-13993604
]
Rick Hillegas commented on DERBY-6554:
--------------------------------------
If tests pass cleanly on that last rev of the patch, we can choose which
behavior is better:
1) derby-6554-02-ae-selfDeadlock_sps_compress.diff - This rev of the patch
raises a SelfDeadlock exception whenever a parent transaction is blocking a
nested subtransaction and the subtransaction can't get a lock immediately.
2) derby-6554-02-af-askToRaiseSelfDeadlock.diff - This rev of the patch lets
the caller choose whether a SelfDeadlock exception should be thrown or whether
lockObject() should just return null if it can't grab a lock immediately. The
null return value does not distinguish SelfDeadlock from
BlockedByAnotherConnection.
I think I understand your preference for the first solution. I can run an
experiment with that patch to see what breaks if SelfDeadlock is raised when
the caller is willing to wait. Having gotten to this point and seen how many
parts of the code use nested subtransactions, I just want to raise a warning
flag that this may break a lot of tests and create backward compatibility
problems because SelfDeadlock will be thrown in cases where the user
application is expecting LockTimeout. It may be better to pursue this
improvement in a separate issue.
> 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, D6554_2.java,
> derby-6554-01-aa-useCreationTransaction.diff,
> derby-6554-01-ab-useCreationTransaction.diff,
> derby-6554-01-ac-useCreationTransaction.diff, derby-6554-01-ad-bugfixes.diff,
> derby-6554-02-aa-selfDeadlock.diff, derby-6554-02-ab-selfDeadlock.diff,
> derby-6554-02-ac-selfDeadlock.diff,
> derby-6554-02-ae-selfDeadlock_sps_compress.diff,
> derby-6554-02-af-askToRaiseSelfDeadlock.diff,
> derby-6554-02-ag-raiseSelfDeadlockAlways.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)
