db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raghavendra Neelekani (JIRA)" <j...@apache.org>
Subject [jira] [Created] (DERBY-6277) Derby still dead locks while freezing and unfreezing
Date Thu, 27 Jun 2013 17:13:23 GMT
Raghavendra Neelekani created DERBY-6277:
--------------------------------------------

             Summary: Derby still dead locks while freezing and unfreezing
                 Key: DERBY-6277
                 URL: https://issues.apache.org/jira/browse/DERBY-6277
             Project: Derby
          Issue Type: Bug
          Components: JDBC, Network Server
    Affects Versions: 10.10.1.1
         Environment: Java 1.6, Linux and Windows, Network Derby Server 10.10.1.1
            Reporter: Raghavendra Neelekani
            Priority: Blocker


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, only one thread which does 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). But 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 we remove the code which does freeze and unfreeze, then it works. This issue happens only
if we put freeze and unfreeze. 
Could you please tell me whats happening here  and provide a fix for this ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message