myKey makes it impossible to implement distributed locks under multiple instances using concurrency

ihezebin commented 1 year ago

Bug report criteria

[X] This bug report is not security related, security issues should be disclosed privately via security@etcd.io.
[X] This is not a support request, support requests should be raised in the etcd discussion forums.
[X] You have read the etcd bug reporting guidelines.
[X] Existing open issues along with etcd frequently asked questions have been checked and this is not a duplicate.

What happened?

This causes the key and release ID to be forcibly bound together, If I have 2 pod instances in the k8s cluster, using concurrency. NewMutex() to implement distributed locks will result in inconsistent release IDs, unless I specify a release ID when creating a session, which will cause me to manually create a release each time I go online.

In fact, I hope that myKey is the same for the same object in different instances, so that they can compete for locks in concurrency.

The current situation may seem more suitable for implementing distributed locks in singletons, but since they are all singletons, why don't I use Golang's official mutex

What did you expect to happen?

I hope to provide configurable parameter selection for the composition of myKey in future versions

How can we reproduce it (as minimally and precisely as possible)?

just double handle

Anything else we need to know?

No response

Etcd version (please run commands below)

etcdctl version: 3.4.27 API version: 3.4

go.etcd.io/etcd/client/v3 v3.5.9

Etcd configuration (command line flags or environment variables)

No response

Etcd debug information (please run commands below, feel free to obfuscate the IP address or FQDN in the output)

No response

Relevant log output

No response

flyingrx commented 1 year ago

You maybe misunderstand the code. Watch the fragment getOwner := v3.OpGet(m.pfx, v3.WithFirstCreate()...). The code will still get the revision of the original key(with a '/'), not key/lease. Then it can check the revision is whether belonging to it's client. If the revision is consistent, then the lock can be got.

stale[bot] commented 7 months ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

etcd-io / etcd