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

Clarification: What should pub.Database.Lock do if a lock is already held? #140

Open
BenLubar opened this issue Aug 11, 2020 · 1 comment

Comments

@BenLubar
Copy link
Contributor

Does go-fed expect pub.Database.Lock to keep trying until the context expires, or should pub.Database.Lock immediately return an error if the lock is already held on a URL?

@cjslep
Copy link
Member

cjslep commented Aug 12, 2020

An error returned from any database method will result in go-fed code aborting processing, and will return the underlying error back up to the calling code. I think a reasonable implementation of Lock would be to await for the lock to be available or for the context to expire (for example, due to a deadline-exceeded type of error), and if it is the latter then returning an error. This will let your calling code send a proper HTTP code back to the client.

Since Lock is called for many different kinds of processing though, it is possible for things to only become partially processed. go-fed relies on the interface implementations to support idempotency, so if a caller retries w/ the same payload the processing (ex: "creating an activity in the db") and side effects (ex: "send notification to a user") only happens once.

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

No branches or pull requests

2 participants