[jira] Commented: (DERBY-2911) Implement a buffer manager using java.util.concurrent classes

["Knut Anders Hatlen (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-2911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547789 ] 

Knut Anders Hatlen commented on DERBY-2911:
-------------------------------------------

I think there is another issue similar to the one Jørgen commented on
about holding the lock on an entry while writing it to disk.

When an entry is fetched into the cache (either with create() or
find()), the old buffer manager would release the lock on the cache
before running createIdentity()/setIdentity(). I assumed it released
the lock because it didn't want to block the entire cache while
performing what could be time consuming operations. I have now found
another reason for releasing the lock: When a new container is
created, the call to createIdentity() will look at data in other
containers and therefore reenter the container cache. If we hold the
lock on the entry that is being created, we can possibly run into a
deadlock when the container cache is reentered. Will try to come up
with a fix.

> Implement a buffer manager using java.util.concurrent classes
> -------------------------------------------------------------
>
>                 Key: DERBY-2911
>                 URL: https://issues.apache.org/jira/browse/DERBY-2911
>             Project: Derby
>          Issue Type: Improvement
>          Components: Performance, Services
>    Affects Versions: 10.4.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: cleaner.diff, cleaner.tar, d2911-1.diff, d2911-1.stat, d2911-2.diff, d2911-3.diff, d2911-4.diff, d2911-5.diff, d2911-6.diff, d2911-6.stat, d2911-7.diff, d2911-7a.diff, d2911-9.diff, d2911-9.stat, d2911-entry-javadoc.diff, d2911-unused.diff, d2911-unused.stat, d2911perf.java, derby-2911-8.diff, derby-2911-8.stat, perftest6.pdf, poisson_patch8.tar
>
>
> There are indications that the buffer manager is a bottleneck for some types of multi-user load. For instance, Anders Morken wrote this in a comment on DERBY-1704: "With a separate table and index for each thread (to remove latch contention and lock waits from the equation) we (...) found that org.apache.derby.impl.services.cache.Clock.find()/release() caused about 5 times more contention than the synchronization in LockSet.lockObject() and LockSet.unlock(). That might be an indicator of where to apply the next push".
> It would be interesting to see the scalability and performance of a buffer manager which exploits the concurrency utilities added in Java SE 5.

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