You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some cases, I'd want to have a lock that does not immediately throw an exception, but that waits until the resource is released.
Probably this would need another timeout setting to configure how long the thread waits for the lock (and only raises an exception when the lock is not released within that time frame).
In its most basic form, I guess this would just be a busy wait.
I can also think of scenarios where this might be interesting in an asynchronous context, but this would probably require a rewrite of substantial parts of the library, due to the normal database access in Django being synchronized?
Do you agree with this idea, or do you think it's up to the application to wait and retry the corresponding task in case an exception occurs?
The text was updated successfully, but these errors were encountered:
Agree with the idea of waiting with timeout. Should application retry or not I'd give to decide for the developer using this package.
And this is not so easy to implement. Simple select_for_update might not work because of transaction isolation levels in different engines. Spin lock will be rather heavy and affect GIL.
For this moment I'd prefer different back-end for locks with waiting like ETCD or redis allowing subscriptions.
In some cases, I'd want to have a lock that does not immediately throw an exception, but that waits until the resource is released.
Probably this would need another timeout setting to configure how long the thread waits for the lock (and only raises an exception when the lock is not released within that time frame).
In its most basic form, I guess this would just be a busy wait.
I can also think of scenarios where this might be interesting in an asynchronous context, but this would probably require a rewrite of substantial parts of the library, due to the normal database access in Django being synchronized?
Do you agree with this idea, or do you think it's up to the application to wait and retry the corresponding task in case an exception occurs?
The text was updated successfully, but these errors were encountered: