You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
Namespace Lock Contentions
Hi all,
I have read the Data Ingress guide and I have some follow up questions about namespace lock contentions:
1) Is the lock set through the entire write operation (e.g. If I am uploading a file to a folder, is the lock set on the folder's namespace untill the end of the upload). I have tried to invite/remove members from a folder while uploading a file and I have not encountered the too_many_write_operations exception, even though I expected I would.
2) Do the API's /create_folder and /share_folder (used to create a shared folder) set namespace locks?
3) Is there a way to check for a namespace lock prior to a write action/operation, or is retrying it using the information from Retry_After header the best practice in handling lock contentions?
1) We don't have documentation or make guarantees as to when exactly during the lifecycle of an API call the locks are taken. It might be the case, for example, that the lock is only taken at the end of the upload, once all of the data has been transmitted. That's not officially guaranteed though, so I can't recommend relying on that. (Also, adding/removing members from an existing shared folder doesn't change the contents of the folder, or the folder itself, so you may not run in to contention with that in particular anyway.)
2) Yes, in general, anything that's making a change to the contents of a namespace (or the namespace's folder itself) is likely to be taking a lock for that namespace.
3) No, there isn't a way to proactively check for a current namespace lock. You'll need to catch the exception and retry as you mentioned.
- Greg-DB
Dropbox Staff
1) We don't have documentation or make guarantees as to when exactly during the lifecycle of an API call the locks are taken. It might be the case, for example, that the lock is only taken at the end of the upload, once all of the data has been transmitted. That's not officially guaranteed though, so I can't recommend relying on that. (Also, adding/removing members from an existing shared folder doesn't change the contents of the folder, or the folder itself, so you may not run in to contention with that in particular anyway.)
2) Yes, in general, anything that's making a change to the contents of a namespace (or the namespace's folder itself) is likely to be taking a lock for that namespace.
3) No, there isn't a way to proactively check for a current namespace lock. You'll need to catch the exception and retry as you mentioned.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
