[
https://issues.apache.org/jira/browse/DERBY-4437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253433#comment-13253433
]
Rick Hillegas commented on DERBY-4437:
--------------------------------------
A next attempt to improve the concurrency of identity columns could build on
Mike' suggestion on DERBY-5493 that we create an internal sequence generator
(represented in SYSSEQUENCES) for every identity column. Here are some ideas
about this approach:
1) I think that we could use SYSCOLUMNS.COLUMNDEFAULTID to hold the uuid of the
internal sequence (SYSSEQUENCES.SEQUENCEID). I think this should be ok because
you can't declare a default value for an identity column. This would make it
relatively easy to find the internal sequence backing an identity column.
2) We could add a SYSCS_UTIL.PEEK_AT_IDENTITY() function to retrieve the
instantaneous current value of the identity column. This would be similar to
the SYSCS_UTIL.PEEK_AT_SEQUENCE() function introduced by DERBY-5493.
> Concurrent inserts into table with identity column perform poorly
> -----------------------------------------------------------------
>
> Key: DERBY-4437
> URL: https://issues.apache.org/jira/browse/DERBY-4437
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 10.5.3.0
> Reporter: Knut Anders Hatlen
> Fix For: 10.9.0.0
>
> Attachments: D4437PerfTest.java, D4437PerfTest2.java,
> Experiments_4437.html, derby-4437-01-aj-allTestsPass.diff,
> derby-4437-02-ac-alterTable-bulkImport-deferredInsert.diff,
> derby-4437-03-aa-upgradeTest.diff,
> derby-4437-04-aa-reclaimUnusedValuesOnShutdown.diff,
> derby-4437-05-aa-pluggablePreallocation.diff,
> derby-4437-06-aa-selfTuning.diff,
> derby-4437-07-ac-biggerDefault_propertyCanBeInteger.diff,
> derby-4437-07-ad-biggerDefault_propertyCanBeInteger.diff,
> derby-4437-08-aa-10.8upgrade.diff, insertperf.png, insertperf2.png,
> prealloc.png, releaseNote.html
>
>
> I have a multi-threaded application which is very insert-intensive. I've
> noticed that it sometimes can come into a state where it slows down
> considerably and basically becomes single-threaded. This is especially
> harmful on modern multi-core machines since most of the available resources
> are left idle.
> The problematic tables contain identity columns, and here's my understanding
> of what happens:
> 1) Identity columns are generated from a counter that's stored in a row in
> SYS.SYSCOLUMNS. During normal operation, the counter is maintained in a
> nested transaction within the transaction that performs the insert. This
> allows the nested transaction to commit the changes to SYS.SYSCOLUMN
> separately from the main transaction, and the exclusive lock that it needs to
> obtain on the row holding the counter, can be releases after a relatively
> short time. Concurrent transactions can therefore insert into the same table
> at the same time, without needing to wait for the others to commit or abort.
> 2) However, if the nested transaction cannot lock the row in SYS.SYSCOLUMNS
> immediately, it will give up and retry the operation in the main transaction.
> This prevents self-deadlocks in the case where the main transaction already
> owns a lock on SYS.SYSCOLUMNS. Unfortunately, this also increases the time
> the row is locked, since the exclusive lock cannot be released until the main
> transaction commits. So as soon as there is one lock collision, the waiting
> transaction changes to a locking mode that increases the chances of others
> having to wait, which seems to result in all insert threads having to obtain
> the SYSCOLUMNS locks in the main transaction. The end result is that only one
> of the insert threads can execute at any given time as long as the
> application is in this state.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
