-
Notifications
You must be signed in to change notification settings - Fork 11
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
Add ID resolver for AWS lambda #10
base: main
Are you sure you want to change the base?
Conversation
|
||
public function __destruct() | ||
{ | ||
$this->release(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we do an App::terminating
callback in the constructor rather than a destruct?
Or we might end up releasing before verbs commits?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the advantage of App::terminating
over __destruct
? I think destruct is a little more flexible, but I could be wrong…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If destruct happens after laravel tears down, could the cache be disconnected?
Snowflakes/etc rely on unique datacenter and worker IDs to operate. Because AWS lambdas are different machines each time, it's impossible to assign each a unique worker/device ID.
This PR adds a new ID resolution mechanism that uses cache locks to acquire a unique ID when required, and then release that ID when the process is terminated. This means that you can effectively have 1024 processes generating unique snowflake IDs in parallel.
By default, Bits will use this mechanism if the
AWS_LAMBDA_FUNCTION_NAME
environmental variable is set.