[
https://issues.apache.org/jira/browse/DERBY-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14191027#comment-14191027
]
Mike Matrigali commented on DERBY-4057:
---------------------------------------
For a first pass at this will look at solving the runtime rollback case. Redo
recovery after system crash
is harder as the recovery happens with only the raw store running, so the
normal post commit machinery
is not available.
To solve this the raw store needs to "call back" into the higher level Access
module to do post commit processing.
This is similar to what the raw store does during logical recovery, calling
back into btree code to do search for a
row that may have moved pages because of splits or joins.
I think simplest will be adding an interface to register a class with raw store
that it can call when it does an undo of
an insert. Then building an access level class that can take the information
raw store provides, funnel it to the correct
conglomerate implementation, and do the appropriate work of queueing a post
commit action using similar logic
to what those conglomerates do today for delete.
> 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
>
> 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)
