db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4050) Multithreaded clob update causes growth in table that does not get reclaimed
Date Mon, 09 Feb 2009 11:24:59 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671809#action_12671809
] 

Kristian Waagan commented on DERBY-4050:
----------------------------------------

I applied the patch and ran the test, which succeeded.
When I removed the fix in ReclaimSpaceHelper, the test failed as expected. I have also started
the regression tests.

Besides from two formatting issues (line 41 and 93 in the diff), the patch looks good to me.
I can't say if calling getPage instead of getPageNoWait is okay without looking more into
the code (i.e. how / if it affects the flow), but I see that you have gotten confirmation
on this already.
I also understand that if we get into the situation that causes growth, a sane Derby build
will fail iff a specific debug flag is set, otherwise it will forget about the "lost space"
and continue to operate as normal.

> 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
>
>
> 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.


Mime
View raw message