[
https://issues.apache.org/jira/browse/DERBY-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811747#comment-13811747
]
Marty Backe edited comment on DERBY-6398 at 11/1/13 11:14 PM:
--------------------------------------------------------------
I created a standalone app to demonstrate the problem, but unfortunately it is
not failing at the Freeze command.
In our production application, there is extensive interaction with the database
before the described scenario (saving a large record and then Freezing) is
executed. So unfortunately it does not appear that I can provide a small app
that demonstrates the failure.
One additional bit of information may provide some more insight:
If, after writing the large record to the database, a subsequent small record
is updated (e.g., changing a boolean value) before the Freeze command is
issued, the Freeze command does not block forever (i.e., the failure does not
occur).
I believe this is consistent with our current workaround 'fix', to execute the
Checkpoint command to flush everything to the disk before performing the Freeze
command. The additional record update forces the previous table update to get
flushed to the disk.
So perhaps the Freeze command fails when there is data in the cache. And for
the small standalone app that I created, the cache is not being utilized, so
therefore it does not fail.
All conjecture on my part - not having any knowledge of the inner workings of
Derby.
If there is some additional instrumentation that I can add to our application
that would provide you with the required data, please let me know.
was (Author: martybacke):
I created a standalone app to demonstrate the problem, but unfortunately it is
not failing at the Freeze command.
In our production application, there is extensive interaction with the database
before the described scenario (saving a large record and then Freezing) is
executed. So unfortunately it does not appear that I can provide a small app
that demonstrates the failure.
One additional bit of information may provide some more insight:
If, after writing the large record to the database, a subsequent small record
is updated (e.g., changing a boolean value) before the Freeze command is
issued, the Freeze command does not block forever (i.e., the failure does not
occur).
I believe this is consistent with our current workaround 'fix', to execute the
Checkpoint command to flush everything to the disk before performing the Freeze
command. The additional record update forces the previous table update to get
flushed to the disk.
So perhaps the Freeze command fails when there is data in the cache. And for
the small standalone app that I created, the cache is not being utilized, so
therefore it does not fail.
All conjecture on my part - not having any knowledge of the inner workings of
Derby.
> 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)
