[
https://issues.apache.org/jira/browse/DERBY-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13907363#comment-13907363
]
Marty Backe commented on DERBY-6277:
------------------------------------
See https://issues.apache.org/jira/browse/DERBY-6398 for the root cause of this
problem. Also, there is a work-around described in the bug submittal text that
can be used until this is fixed.
> 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, 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 ?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
