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.
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.