[
https://issues.apache.org/jira/browse/DERBY-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-4050:
----------------------------------
i am surprised it is latch contention and not lock contention, but does make
sense that it becomes bigger and bigger problem the more concurrent the JVM and
multi-processors. In this case I think we should just wait on the latch rather
than retry.
Try getPage() instead of getPageNoWait()
> 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
> Attachments: ClobGrowth.java, 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.
