-
Notifications
You must be signed in to change notification settings - Fork 6
fix: address more concurrency concerns in caching client #114
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
Conversation
Codecov Report
@@ Coverage Diff @@
## main #114 +/- ##
============================================
- Coverage 59.78% 59.77% -0.02%
Complexity 295 295
============================================
Files 39 39
Lines 2979 2978 -1
Branches 368 368
============================================
- Hits 1781 1780 -1
Misses 1026 1026
Partials 172 172
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
This comment has been minimized.
This comment has been minimized.
| // Acquire write lock to ensure no more modification of this update | ||
| Lock lock = pendingUpdateStripedLock.get(entityKey).writeLock(); | ||
| // Make sure no current additions | ||
| Lock lock = pendingUpdateStripedLock.get(entityKey); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
L133 seems redundant since cache update is already done within L132. Can be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
two different uses of the word cache.
Single<Entity> updateResult =
EntityDataCachingClient.this.createOrUpdateEntity(entityKey, condition).cache();
Caches in the Single - that is, all subscribers will share a result rather than re-executing
( http://reactivex.io/RxJava/3.x/javadoc/io/reactivex/rxjava3/core/Single.html#cache-- )
EntityDataCachingClient.this.cache.put(entityKey, updateResult);
puts the single itself into the guava cache for future callers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but if we go inside:
private Single<Entity> createOrUpdateEntity(
EntityKey entityKey, UpsertCondition upsertCondition) {
Single<Entity> updateResult =
this.upsertEntityWithoutCaching(entityKey, upsertCondition).cache();
EntityDataCachingClient.this.cache.put(entityKey, updateResult);
return updateResult;
}
that is already adding the single within the guava cache, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for following up on this, my mind is clearly all over the place 🙁 - addressed.
Description
Switching from a RW lock to mutual exclusion since adding updates is also not thread safe.