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
Hi @bymyslf , there are several things preventing from using advisory locks:
pg_advisory_lock accepts only integer values whereas hangfire needs a string for the key
advisory locks are binded to current session whereas hangfire lock owner can release the lock via different connection/session
I had a long journey investigating the most "natural" way to implement distributed locks in pg and finally I came to this but it's applicable for pg versions 9.6 and above.
Hi @ahydrax, the first point is quite embarrassing for me. I was fully confident that the job ID was used as the resource and didn't check twice. Confused with another project that uses distributed locks.
However, even if the job ID was the resource, your second point invalidates the "native" locks.
Is there anything that prevents the use of the advisory locks instead of the lock table?
IMO, it would be better to use the native functions. What do you think?
https://www.postgresql.org/docs/9.4/static/explicit-locking.html
The text was updated successfully, but these errors were encountered: