Uploaded image for project: 'Derby'
  1. Derby
  2. DERBY-733

Starvation in RAFContainer.readPage()

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 10.1.2.1, 10.1.3.1, 10.2.1.6
    • 10.2.1.6
    • Store
    • None
    • Solaris x86 and Linux with Sun JVM 1.5.0. Derby embedded and client/server.
    • Performance

    Description

      When Derby is completely disk bound, threads might be starved in
      RAFContainer.readPage(). This is a real problem when multiple clients
      are repeatedly accessing one or a small number of large tables. In
      cases like this, I have observed very high maximum response times
      (several minutes in the worst cases) on simple transactions. The
      average response time is not affected by this.

      The starvation is caused by a synchronized block in
      RAFContainer.readPage():

      synchronized (this)

      { fileData.seek(pageOffset); fileData.readFully(pageData, 0, pageSize); }

      If many threads want to read pages from the same file, there will be a
      long queue of threads waiting for this monitor. Since the Java
      specification does not guarantee that threads waiting for monitors are
      treated fairly, some threads might have to wait for a long time before
      they get the monitor. (Usually, a couple of threads get full throughput
      while the others have to wait.)

      Attachments

        1. DERBY-733.diff
          3 kB
          Knut Anders Hatlen
        2. DERBY-733-more-exception-handling.diff
          2 kB
          Knut Anders Hatlen
        3. Insert.java
          2 kB
          Knut Anders Hatlen
        4. Select.java
          4 kB
          Knut Anders Hatlen

        Activity

          People

            knutanders Knut Anders Hatlen
            knutanders Knut Anders Hatlen
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: