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

Derby still dead locks while freezing and unfreezing

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Open
    • Priority: Blocker
    • Resolution: Unresolved
    • Affects Version/s: 10.10.1.1
    • Fix Version/s: None
    • Component/s: JDBC, Network Server
    • Labels:
      None
    • Environment:
      Java 1.6, Linux and Windows, Network Derby Server 10.10.1.1
    • Urgency:
      Urgent

      Description

      Apache derby forum says the logical dead lock happened when freezing/unfreezing the database issue (DERBY-5632) is fixed in version 10.10.1.1 but When I tested with this version I still see some deadlocks in derby.
      My flow is like this, multiple threads will be accessing the table and queries for the rows. Here I use hibernate to get all the rows from the table.
      In the above scenario, one thread will freezes the database using the procedure (SYSCS_UTIL.SYSCS_FREEZE_DATABASE) and then queries for the rows and at the end unfreezes the database using procedure (SYSCS_UTIL.SYSCS_UNFREEZE_DATABASE) and all other threads just queries for the rows without freeze/unfreezing.
      This works fine as long as we have less data in the table about 25 rows. (We store huge blob object at each row). But it strucks when there are huge data in the table about more than 30 rows.

      When we look in to the javadump for the call, it shows following stack trace of the thread which does freeze queries and unfreeze

      "http-147.167.56.215-443-3" J9VMThread:0x0D523100, j9thread_t:0x0A172BB4, java/lang/Thread:0x7C5EE4B0, state:CW, prio=5
      native thread ID:0x2222, native priority:0x5, native policy:UNKNOWN)
      (native stack address range from:0x6E5BF000, to:0x6E600000, size:0x41000)
      Java callstack:
      at java/lang/Object.wait(Native Method)
      at java/lang/Object.wait(Object.java:167(Compiled Code))
      at org/apache/derby/impl/store/raw/data/BaseDataFileFactory.writeInProgress(Bytecode PC:3(Compiled Code))
      at org/apache/derby/impl/store/raw/data/RAFContainer.run(Bytecode PC:117)
      at java/security/AccessController.doPrivileged(AccessController.java:251(Compiled Code))
      at org/apache/derby/impl/store/raw/data/RAFContainer.createContainer(Bytecode PC:11)
      at org/apache/derby/impl/store/raw/data/FileContainer.createIdent(Bytecode PC:85)
      at org/apache/derby/impl/store/raw/data/FileContainer.createIdentity(Bytecode PC:33)
      at org/apache/derby/impl/services/cache/ConcurrentCache.create(Bytecode PC:77(Compiled Code))
      at org/apache/derby/impl/store/raw/data/BaseDataFileFactory.addContainer(Bytecode PC:100)
      at org/apache/derby/impl/store/raw/xact/Xact.addContainer(Bytecode PC:19)
      at org/apache/derby/impl/store/access/heap/Heap.create(Bytecode PC:62)
      at org/apache/derby/impl/store/access/heap/HeapConglomerateFactory.createConglomerate(Bytecode PC:95)
      at org/apache/derby/impl/store/access/RAMTransaction.createConglomerate(Bytecode PC:90)
      at org/apache/derby/iapi/store/access/DiskHashtable.<init>(Bytecode PC:153)
      at org/apache/derby/iapi/store/access/BackingStoreHashtable.spillToDisk(Bytecode PC:71(Compiled Code))
      at org/apache/derby/iapi/store/access/BackingStoreHashtable.add_row_to_hash_table(Bytecode PC:2(Compiled Code))
      at org/apache/derby/iapi/store/access/BackingStoreHashtable.putRow(Bytecode PC:71(Compiled Code))
      at org/apache/derby/impl/sql/execute/ScrollInsensitiveResultSet.addRowToHashTable(Bytecode PC:71(Compiled Code))
      at org/apache/derby/impl/sql/execute/ScrollInsensitiveResultSet.getNextRowFromSource(Bytecode PC:172(Compiled Code))
      at org/apache/derby/impl/sql/execute/ScrollInsensitiveResultSet.getNextRowCore(Bytecode PC:60(Compiled Code))
      at org/apache/derby/impl/sql/execute/BasicNoPutResultSetImpl.getNextRow(Bytecode PC:45(Compiled Code))
      at org/apache/derby/impl/jdbc/EmbedResultSet.movePosition(Bytecode PC:162(Compiled Code))
      at org/apache/derby/impl/jdbc/EmbedResultSet.next(Bytecode PC:39(Compiled Code))
      at org/hibernate/loader/Loader.doQuery(Loader.java:672(Compiled Code))
      at org/hibernate/loader/Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236(Compiled Code))
      at org/hibernate/loader/Loader.doList(Loader.java:2216(Compiled Code))
      at org/hibernate/loader/Loader.listIgnoreQueryCache(Loader.java(Compiled Code))
      at org/hibernate/loader/Loader.list(Loader.java:2092(Compiled Code))
      at org/hibernate/loader/hql/QueryLoader.list(QueryLoader.java:378(Compiled Code))
      at org/hibernate/hql/ast/QueryTranslatorImpl.list(QueryTranslatorImpl.java:323(Compiled Code))
      at org/hibernate/engine/query/HQLQueryPlan.performList(HQLQueryPlan.java:172(Compiled Code))
      at org/hibernate/impl/SessionImpl.list(SessionImpl.java:1121(Compiled Code))
      at org/hibernate/impl/QueryImpl.list(QueryImpl.java:79(Compiled Code))

      Here we can see that derby call goes to wait state and never comes back. At this point other threads also cant access the table since it can not get a lock on the table.

      But if we remove the code which does freeze and unfreeze, then it works and there is no deadlock happens. This issue happens only if we put freeze and unfreeze with huge data in the database table.
      Could you please tell me whats happening here and provide a fix for this ?

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              raagu Raghavendra Neelekani
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: