db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4565) Create concurrency test to stress sequence generators.
Date Mon, 08 Mar 2010 21:07:27 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Rick Hillegas updated DERBY-4565:
---------------------------------

    Attachment: derby-4565-02-aa-useWaitTimeout.diff

Attaching derby-4565-02-aa-useWaitTimeout.diff. This patch eliminates the retry count. Instead,
we now use the lock wait timeout to bound how long we attempt to allocate a new cache of sequence
numbers. That is, we raise a "too much contention" exception only if we have looped longer
than the timeout set by derby.locks.waitTimeout.

With this change, the "too much contention" exceptions disappear. Throughput on the experiment
now comes in around 350 tx/sec.

A couple other experiments:

1) I let only one session at a time try to allocate another block of sequence numbers in its
main execution transaction. This reduced throughput to 100 tx/sec.

2) I tried various larger sizes for the number of values pre-allocated in one gulp. The maximum
chunk I tried was 10,000,000 values. This pushed the throughput up to 480 tx/sec. Most of
that boost was achieved by raising the chunk size to only 100 values.

3) I do see sessions failing to get a write lock immediately, and then falling back on their
execution transactions.

4) I don't see any lock timeout exceptions in the test case itself. That is, the test does
not log any of these exceptions. Knut, is it possible that what you are seeing are the subtransactions
failing to get a write lock immediately and then falling back on the parent transaction?

I think this patch by itself is incremental improvement:

A) It eliminates the "too much contention" exceptions.

B) It makes it possible to adjust a pre-existing Derby knob in order to tune the concurrency
of sequence generators.


Touches the following files:

---------------

M      java/engine/org/apache/derby/impl/services/locks/LockTable.java
M      java/engine/org/apache/derby/impl/services/locks/LockSet.java
M      java/engine/org/apache/derby/impl/services/locks/ConcurrentLockSet.java
M      java/engine/org/apache/derby/impl/services/locks/AbstractPool.java
M      java/engine/org/apache/derby/iapi/services/locks/LockFactory.java

Add a new method to the LockFactory so that the factory can report what the lock wait timeout
is.

---------------

M      java/engine/org/apache/derby/impl/sql/catalog/SequenceUpdater.java

Use the lock wait timeout to bound the number of times that a session tries to pre-allocate
a chunk of sequence numbers.


> Create concurrency test to stress sequence generators.
> ------------------------------------------------------
>
>                 Key: DERBY-4565
>                 URL: https://issues.apache.org/jira/browse/DERBY-4565
>             Project: Derby
>          Issue Type: Task
>          Components: SQL, Test
>    Affects Versions: 10.6.0.0
>            Reporter: Rick Hillegas
>            Assignee: Rick Hillegas
>         Attachments: derby-4565-01-ad-firstRev.diff, derby-4565-02-aa-useWaitTimeout.diff
>
>
> Create a concurrency test to find bottlenecks and bugs in sequence generators.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message