[
https://issues.apache.org/jira/browse/DERBY-6554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13993922#comment-13993922
]
Mike Matrigali commented on DERBY-6554:
---------------------------------------
thanks rick for the explanation, i keep forgetting about the shutdown and cache
eviction case. I'll think about
it some more while you are out. But early thoughts would be to take
incremental steps so as to not hold
up your sequence work any more:
1) go with your patch #1 above as it seems to do what you need and passes
tests. I think it only slows
down delete row reclamation with extra exceptions vs returns, so probably
ok. I am ok with the one
store change for now as an incremental step.
2) file a separate JIRA to put in self deadlock detection in for waiting locks.
With your patches the
code is available and work just needs to be done on problems with rest of
code.
3) file a separate JIRA to change 0 wait locks to not throw an exception in
self deadlock. This will need
a solution that works for sequences. Not sure of solution at this point,
would be easy if we can have
sequences wait.
4) test and see if we think sequences would benefit from waiting. If so
figure out how to wait. Current
lock interfaces don't make it easy to set timeout's other than 0 and
default.
I think we want sequences to wait at least as long as we expect another
transaction
to take to update the sequence and commit the transaction on a system that
does a real I/O at commit
time. If waiting does not work out, may still want to try sleep retry now
that we know we are not
in self deadlock vs. sending an error to user. All depends on doing this
without negatively affecting
the shutdown and cache clean cases.
I would be interested in working on #2, as it ties in with work I would like to
do to improve automatic
space reclamation. I think some of the problems in this area are with self
deadlock and waiting may
help. It would be easier to work on this if we separated the dependencies.
Along with #2 I would look
at all the store nested transactions and make sure they are ready and do the
right thing with self
deadlock. I may need help with the language layer uses, but I don't think
there are many other than
sequences and identity.
> 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)
