[
https://issues.apache.org/jira/browse/DERBY-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473247
]
Mike Matrigali commented on DERBY-2337:
---------------------------------------
Here's the comment from the applicable code in FileContainer.java:
{
// transfer the page latch from NTT to UT.
//
// after the page is unlatched by NTT, it is still
// protected from being found by almost everybody else
// because the alloc page is still latched and the alloc
// cache is invalidated.
//
// However it is possible for the page to be
// found by threads who specifically ask for this
// pagenumber (e.g. HeapPostCommit).
// We may find that such a thread has latched the page.
// We shouldn't wait for it because we have the alloc page
// latch, and this could cause deadlock (e.g.
// HeapPostCommit might call removePage and this would wait
// on the alloc page).
//
// We may instead find that we can latch the page, but that
// another thread has managed to get hold of it during the
// transfer and either deallocated it or otherwise change it
// (add rows, delete rows etc.)
//
// Since this doesn't happen very often, we retry in these
// 2 cases (we give up the alloc page and page and we start
// this method from scratch).
//
// If the lock manager were changed to allow latches to be
// transferred between transactions, wouldn't need to
// unlatch to do the transfer, and would avoid having to
// retry in these cases (DERBY-2337).
> allow latches to be transferred directly from nested internal transactions to
> calling user transaction to improve page allocation performance/complexity
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2337
> URL: https://issues.apache.org/jira/browse/DERBY-2337
> Project: Derby
> Issue Type: Improvement
> Components: Store
> Affects Versions: 10.2.2.0
> Reporter: Mike Matrigali
> Priority: Minor
>
> In the newPage() routine of FileContainer.java a new page is allocated using
> a ntt (a nested internal transaction), so that the allocation of the new page
> can be committed separate from the user transaction requesting the
> allocation. Extra logic and time is needed once the page is allocated to
> allow the calling transaction to use it as it must be unlatched and must
> handle other transactions getting to it before it gets a chance. If somehow
> the ntt could be committed but the latch be transferred to the calling
> transaction then the insert would go faster, and there would be no need for
> retry logic.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
