[
https://issues.apache.org/jira/browse/DERBY-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13813929#comment-13813929
]
Knut Anders Hatlen commented on DERBY-6398:
-------------------------------------------
Just to make sure that we're on the right track. Marty, is the following true
about your application:
- the connection that invoked syscs_freeze_database() had auto-commit enabled?
- the large update that was performed prior to the freeze, was done on the same
connection object as the freeze command?
What is the nature of the large update? Is it an INSERT or an UPDATE? Does it
touch a BLOB or a CLOB?
It might provide some useful data if you could compile derby.jar with the
following added to the commitNoSync(int) method in
java/engine/org/apache/derby/impl/store/raw/xact/Xact.java:
Thread.dumpStack();
It would be interesting to see the stack trace of the last call to
commitNoSync() before the freeze call that hangs.
> SYSCS_FREEZE_DATABASE locks-up if there are large records that haven't been
> flushed to the disk
> -----------------------------------------------------------------------------------------------
>
> Key: DERBY-6398
> URL: https://issues.apache.org/jira/browse/DERBY-6398
> Project: Derby
> Issue Type: Bug
> Components: Miscellaneous
> Affects Versions: 10.10.1.1
> Environment: Reliably demonstrated on Windows 7 with JDK 1.6.0_31
> Reporter: Marty Backe
> Fix For: 10.10.1.1
>
> Attachments: report.txt
>
>
> If after writing a record that contains a large data column (>100KB), the
> FREEZE command is issued, the command never returns (Derby appears to be
> dead-locked).
> E.g. sqlStatement.executeUpdate("CALL SYSCS_UTIL.SYSCS_FREEZE_DATABASE()");
> If the CALL SYSCS_UTIL.SYSCS_CHECKPOINT_DATABASE() command is first used
> before calling FREEZE, it does not lock-up.
> It's my opinion that calling FREEZE should never result in a dead-locked
> Derby instance.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
