Skip to content

Limiting number of retries & always unlocking#7

Open
bmalinconico wants to merge 1 commit intoeredi93:masterfrom
bmalinconico:fixing_minor_errors
Open

Limiting number of retries & always unlocking#7
bmalinconico wants to merge 1 commit intoeredi93:masterfrom
bmalinconico:fixing_minor_errors

Conversation

@bmalinconico
Copy link

A couple of fixes:

  1. Always unlock, even if the block throws an error
  2. We shouldn't spin lock forever, I setup a default of 3 retires before it throws. This is a breaking change.

end

def wait_until_lock_obtained(sleep_seconds: 3)
def wait_until_lock_obtained(sleep_seconds: 3, retries: 3)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do agree with the fact that using a spinlock is generally not great but some people may rely on it.
As you said this would be a breaking change and I'd be better to make this change less disruptive.
just out of curiosity, how did you pick that number 3?
I'm thinking that it could be set to 20, with the current 3s sleep it'd wait for ~1min making it a bit less disruptive change.
Otherwise, setting the retries to nil and skip this new logic if retries is not set, could also be a nicer way to introduce this.
would be great to know the reasoning and use cases behind this change

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Three is just the standard for the codebase we are working in. In a high concurrency env we want to just move on to the next work unit if we are unable to obtain a lock.

Perhaps a better way to do this is to add a new method for obtain_lock and keep wait_until_lock_obtained as a spin lock.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the base method that creates the lock is called obtain_lock

def obtain_lock

what about creating a new method called obtain_lock_with_retries?

end

private def process_id
private
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why? I personally prefer the private beside the def making it easier to read git diffs.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my experience calling private with arguments is uncommon. I'm not sure I have ever seen it done that way actually, this is just me reviewing the code as I went through it.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/AccessModifierDeclarations I do prefer inline over group. I moved to the inline a while ago, a prefer it as is more explicit and it helps with diffs. We use it at work as well.
I actually should add rubocop sometimes this week


yield(locker)

ensure
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

raise(MissingParameterError, "DynamoDB Hash Key not set")
elsif opts[:hash_key].nil?
raise(MissingParameterError, "DynamoDB Table not set")
elsif opts[:hash_key].nil?
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for spotting this 🙇

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants