Hacker News new | ask | show | jobs
by rand_r 810 days ago
That is the way, but the UX is pretty ass because the lock ID is a 64 bit number instead of a string. How the heck are you supposed to keep track of what lock ID you should be checking in a given situation across multiple client apps?
2 comments

You get the same problem for strings. How do you know that you should lock "user_update" and not "update_user" for example? And how do you avoid name collision when client A wants to check for a lock that is used by client B for other purposes?

The solution to both cases is to define them as either static constants or use an Enum. Then you would not care if the end result is a string or a number.

At my work place we simply have a static class with lock names that we use.

Good point, that’s a better approach. I guess for a multi-repo situation at work, you would need to create a base project like “postgres-lock-ids” so you can synchronize the lock across everything.
hashtext() works well