Skip to content

Create a lock abstract layer and remove old one #22176

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

Closed
wants to merge 27 commits into from

Conversation

lunny
Copy link
Member

@lunny lunny commented Dec 20, 2022

This PR introduce an abstract lock layer. For a single instance, just use memory lock which is default value. For a multiple instances deployment, change to a distributed lock based on redis.

Try to fix ##19620

@lunny lunny added the type/refactoring Existing code has been cleaned up. There should be no new functionality. label Dec 20, 2022
@lunny lunny added this to the 1.19.0 milestone Dec 20, 2022
@silverwind
Copy link
Member

Need to run make tidy.

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Dec 20, 2022
@lunny
Copy link
Member Author

lunny commented Dec 21, 2022

Details

The error is returned argument hasn't been handled.

@lunny lunny changed the title WIP: create a lock abstract layer and remove old one Create a lock abstract layer and remove old one Dec 27, 2022
@lunny
Copy link
Member Author

lunny commented Dec 27, 2022

Need to run make tidy.

Resolved.

@KN4CK3R
Copy link
Member

KN4CK3R commented Dec 31, 2022

Build error is related.

@codecov-commenter

This comment was marked as off-topic.

Copy link
Contributor

@wxiaoguang wxiaoguang left a comment

Choose a reason for hiding this comment

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

Just a brief review, I think there are some bugs and some designs are wrong.

  • Old StartIfNotRunning won't block if it can not acquire the lock, it's incorrect to replace it directly by Lock
  • In TransferOwnership, the same lock is locked twice without unlocking the previous lock
  • The Redis lock behavior is totally different from the internal lock. Redis lock will return error in 8 seconds if the lock can not be acquired, it might break the old logic -- which expects the lock can be acquired in the end without error.

@lunny lunny modified the milestones: 1.19.0, 1.20.0 Feb 4, 2023
@lunny lunny mentioned this pull request May 3, 2023
8 tasks
## Sync (`sync`)

- `LOCK_SERVICE_TYPE`: **memory**: Lock service type, could be `memory` or `redis`
- `LOCK_SERVICE_CONN_STR`: **\<empty\>**: Ignored when `LOCK_SERVICE_TYPE` is `memory` type, for `redis`, it likes `addrs=127.0.0.1:6379 db=0`
Copy link
Contributor

Choose a reason for hiding this comment

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

shouldn't this use the same connection string format which the other redis types are using?

@GiteaBot GiteaBot added lgtm/blocked A maintainer has reservations with the PR and thus it cannot be merged and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels May 3, 2023
@delvh delvh removed this from the 1.20.0 milestone Jun 7, 2023
@lunny
Copy link
Member Author

lunny commented Aug 14, 2023

Please follow #26486

@lunny lunny closed this Aug 14, 2023
@lunny lunny deleted the lunny/lock_interface branch August 14, 2023 06:20
@go-gitea go-gitea locked as resolved and limited conversation to collaborators Nov 12, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
lgtm/blocked A maintainer has reservations with the PR and thus it cannot be merged type/refactoring Existing code has been cleaned up. There should be no new functionality.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants