[
https://issues.apache.org/jira/browse/DERBY-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-4050:
----------------------------------
Derby Info: [Patch Available, Release Note Needed] (was: [Release Note
Needed, Patch Available])
the patch and the test look good to me. I have the following suggestions which
are not necessary for committing the fix.
o maybe add the same comment from other places in the code to the new code that
replaces the retry. I can't think of any reason
we would get a null here so I don't think retry is worth it, and shutting
down the system is not going to help, but it is a silent failure
of the reclaim code - around line 380:
// If code gets here, the space will be lost forever, and
// can only be reclaimed by a full offline compress of the
// table/index.
o i think the test for checkin is fiine. It might be interesting to just see
what happens if you bump the number of concurrent threads
way up to 100 or so. It may not matter much if the machine you run on is
only dual core, but probably worth one run. maybe we can
get someone on the list with an 8+ way to run the test with concurrent users
bumped up?
o i think it would be worth it to file at least jira tasks for investigating
the other 2 paths in the code that might leave unreclaimed space.
as I said I am surprised the row lock path didn't fire. I think one could
make the table open path fire if the test were modified to
force table level exclusive locking - hopefully a much less likely scenario
for user applications. it might take different statements also.
> Multithreaded clob update causes growth in table that does not get reclaimed
> ----------------------------------------------------------------------------
>
> Key: DERBY-4050
> URL: https://issues.apache.org/jira/browse/DERBY-4050
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.0.0
> Reporter: Kathey Marsden
> Assignee: Kathey Marsden
> Attachments: ClobGrowth.java, derby-4050_diff.txt,
> derby-4050_more_debug.diff, derby.log.growth, derby.log.nogrowth,
> releaseNote.html
>
>
> Doing a multithreaded update of a Clob table causes table growth that does
> not get reclaimed except by compressing the table. The reproduction has a
> table with two threads. One thread updates row 1 repeatedly with 33,000
> character clob. The other thread updates row 2 with a small clob, "hello".
> The problem occurs back to 10.2 but seems much worse on trunk than 10.2.
> The trunk database grew to 273MB on trunk after 10000 updates of each row.
> The 10.2 database grew only to 25MB. If the update is synchronized there is
> no growth.
> I will attach the repro.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
