[#2780] Improvement(server,core): Move tree lock from rest api to the corresponding implementation to minimize tree lock range. #2873
Conversation
| }); | ||
| Table loadTable = dispatcher.loadTable(tableIdent); | ||
|
|
||
| Partition p = |
There was a problem hiding this comment.
As we have moved the logic about tree lock into dispatcher, for partitioning-related logic, we can't completely remove tree lock from APIs.
This seems to be not very elegant, but I can't find a better one till now.
There was a problem hiding this comment.
The change here will possibly lead to inconsistency, right?
There was a problem hiding this comment.
Yeah, I'm working on it.
There was a problem hiding this comment.
In case of this, I would rethink the necessity of this change.
There was a problem hiding this comment.
OK, I have some doubts about whether PR is necessary.
There was a problem hiding this comment.
You can defer this and work on others firstly.
|
@yuqi1129 I'm going to close this first. We can reopen this when we feel necessary to change and have a better solution. |
Got it |
|
I think you can do some fine-grained access control for the lock scope, rather than blindly wrapping the whole logic into one lock. For example, like "load fileset", you only need to lock the |
What changes were proposed in this pull request?
Modify the rest API and move the tree lock to the core module.
Why are the changes needed?
The rest API should not be locked entirely by a tree lock.
Fix: #2780
Does this PR introduce any user-facing change?
N/A.
How was this patch tested?
N/A.