-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: revert lock less when syncing #1026
fix: revert lock less when syncing #1026
Conversation
@tangyang9464 @closetool @sagilio please review |
@johanneswuerbach plz fix: |
This reverts commit 756b994.
8cc7c19
to
6d50a0f
Compare
@hsluoyz fix pushed. |
@johanneswuerbach Maybe we don't need to revert, just add a read lock to |
That won’t work as an open read lock blocks any writes and there is no way to upgrade a read to write lock in RWMutex today golang/go#38859 (comment) |
@johanneswuerbach I don't understand very well, isn't our goal to add RLock, only allow reading and not writing? My code is
|
@tangyang9464 sorry I misunderstood your proposal. Line 440 in 290ed05
|
@johanneswuerbach yes, we need use new |
Hey @tangyang9464, my company is likely migrating away from casbin due to several scalability issues discovered with our usage and the intransparent maintainer decision making, so I won't have much time to implement those changes. I just wanted to revert this change, as I've originally introduced it in #1026. |
🎉 This PR is included in version 2.47.2 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Reverts #988
This change can cause races when the management api is used while a new model is being prepared.
Situation:
newModel
model
withnewModel
In this case the write in T2 would not be present until the next reload.
Sadly that brings back the issue that slow policy loading stalls any enforcements. One option might be to use a different lock for such performance critical operation and accept a certain degree of eventual consistency.