Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Try wrapping restoreBlocks in a single atomically #1659

Merged
merged 1 commit into from
May 13, 2020

Conversation

Anviking
Copy link
Member

@Anviking Anviking commented May 13, 2020

Issue Number

#1644

Overview

  • 2772f41
    📍 Also restore blocks within a single atomic operation.
    This is to cope with concurrent requests that could come at the same
    time we are restoring blocks and would modify the internal state
    associated with checkpoints. Here's a scenario of interleaved actions
    in different threads:

    a) Thread 1: 'restoreBlocks' is triggered and fetch cp0 from the database.
    b) Thread 2: A request for creating an address is received. We fetch cp0
    c) Thread 1: Blocks are restored, and new checkpoints are created from cp0
    d) Thread 2: A new address is added, and cp0 is replaced by cp0'
    e) Thread 1: cp1 ... cpN are inserted, but they're all missing the address from cp0'!

    A side-effect of this is that it will make the restore block operation
    blocking for longer, which could possibly be an issue in restoration
    mode where requests are consumed in a fast pace. Concurrent requests
    will likely be slower.

Co-Authored-By: @Anviking

edited by @KtorZ

  This is to cope with concurrent requests that could come at the same
  time we are restoring blocks and would modify the internal state
  associated with checkpoints. Here's a scenario of interleaved actions
  in different threads:

  a) Thread 1: 'restoreBlocks' is triggered and fetch `cp0` from the database.
  b) Thread 2: A request for creating an address is received. We fetch `cp0`
  c) Thread 1: Blocks are restored, and new checkpoints are created from `cp0`
  d) Thread 2: A new address is added, and `cp0` is replaced by `cp0'`
  e) Thread 1: `cp1` ... `cpN` are inserted, but they're all missing the address from `cp0'`!

  A side-effect of this is that it will make the restore block operation
  blocking for longer, which could possibly be an issue in restoration
  mode where requests are consumed in a fast pace. Concurrent requests
  will likely be slower.

Co-Authored-By: @Anviking
@KtorZ KtorZ force-pushed the anviking/1644/more-atomically branch from 6f94f9d to 2772f41 Compare May 13, 2020 13:58
@KtorZ KtorZ marked this pull request as ready for review May 13, 2020 15:08
@KtorZ
Copy link
Member

KtorZ commented May 13, 2020

bors r+

@iohk-bors
Copy link
Contributor

iohk-bors bot commented May 13, 2020

@iohk-bors iohk-bors bot merged commit b3f51ab into master May 13, 2020
@iohk-bors iohk-bors bot deleted the anviking/1644/more-atomically branch May 13, 2020 15:49
@KtorZ KtorZ added the RESOLVING ISSUE Mark a PR as resolving issues, for auto-generated CHANGELOG label May 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RESOLVING ISSUE Mark a PR as resolving issues, for auto-generated CHANGELOG
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants