[
https://issues.apache.org/jira/browse/DERBY-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14204050#comment-14204050
]
Mike Matrigali commented on DERBY-4057:
---------------------------------------
I think your understanding is correct. The intent is to make the space
reclaiming process of
an aborted insert to match as closely as possible the existing behavior of
space reclamation
of a committed delete.
In both cases it is necessary to delay any reclaiming of the space on a page
until after the
transaction has successfully committed or aborted. This insures that redo
recovery of the
committed transaction and aborted transactions will always succeed. If we
removed the
space of a delete before commit some other transaction could use that space
before we
committed and then the abort of the delete could find there was not enough
space to put
the data back on the page.
The work gets queued after commit or abort. Usually this work is then done
async to the
user thread by the raw store daemon. This is often an issue with some
intermittent test results across platforms that
"expect" some amount of space reclamation, but sometimes get different results.
> Space is not reclaimed if transaction is rolled back
> ----------------------------------------------------
>
> Key: DERBY-4057
> URL: https://issues.apache.org/jira/browse/DERBY-4057
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.5.1.1
> Reporter: Kathey Marsden
> Assignee: Mike Matrigali
> Labels: derby_triage10_5_2, derby_triage10_9
> Attachments: DERBY-4057_initial_prototype_patch.diff
>
>
> If I repeatedly insert into a clob table and rollback the the transaction the
> space is not reclaimed and the number of allocated pages continues to grow.
> I will add a test case to ClobReclamationTest and reference this bug.
> DERBY-4056 may be a special case of this bug, but I thought I would file a
> bug for the general issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
